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Amazon.com: 
Part of the Problem 



Walt Disney once said, 
''People spend money 
when and where they 
feel good;" and even 
in these days of shopping from web 
sites, I think his observation still holds 
true. For me, Amazon.com was such a 
place for a number of years. For a long 
time I enjoyed the site and spent quite 
a bit of money on books and movies 
there. But recently that changed. I 
joined the Amazon boycott. 

Back in 1997, Amazon decided to file 
a patent on ''one-click ordering." This is 
a system whereby you select an item to 
purchase, and using a unique identifier 
on your computer (like a cookie), the 
server takes you to a checkout screen 
containing your previously-entered 
identification, greatly simplifying the 
transaction for the customer. Amazon 
received the patent for this system last 
fall (U.S. Patent Number 5,960,411). 

The fact that this patent was award- 
ed speaks little (or perhaps volumes) 
about the patent office. It's my opinion 
that this government agency, like 
many others, is underfunded, under- 
staffed, and will probably continue to 
blunder along as technology zooms 
ahead. So don't be surprised if we con- 
tinue to see other idiotic patents 
awarded in the future. 

That's the government's excuse. 
What about Amazon? On one hand, I 
can see a company wanting to stake a 
claim on a process as a defensive move. 
After all, if someone's going to snag a 
patent that affects your business, and 
philosophically you detest software 
patents, common sense dictates that 
it's better you than your competitor. 
(As someone once told me, "If you're 
not part of the problem, you're getting 
screwed.") 

But Amazon demonstrated that it 
wanted the patent for more than just 
an insurance policy. Within a week of 
being awarded the "one-click" patent, 
Amazon promptly sued its arch rival, 
BarnesandNoble.com, for patent 
infringement. Right out of the chute, 
Amazon used the patent as an offensive 
weapon. More recently in February, 
Amazon locked up a patent on Internet 



affiliate programs in which associate 
web sites are given a commission for 
each referral to Amazon. It's not clear 
how aggressively the company plans to 
enforce that patent, but given its track 
record, I'm not optimistic. 

If you're wondering what Amazon's 
patent has to do with game develop- 
ment, look around you. Any patent that 
puts a stranglehold on Internet com- 
merce affects the games business. Selling 
games direct over the web is big busi- 
ness for game publishers, and if this sort 
of ridiculous patent is any indication of 
e-commerce's future, we're all in for a 
rough ride. This patent stampede has 
plenty of potential to trample us all, and 
whether or not you believe that Ama- 
zon will bully your company tomorrow, 
imagine if the next e-commerce patent 
— let alone one governing a well-estab- 
lished in-game process — is snagged by 
your direct competitor. 

It's possible, even probable, that 
many Internet patents being awarded 
today won't hold up in court. But since 
the high cost of defending a patent case 
naturally favors large companies who 
can afford protracted court battles, it's 
the little companies that are most 
threatened by the rush to patent mun- 
dane computational processes. Burgeon- 
ing game development companies 
should spend their money developing 
games, not on lawsuits brought on by 
deep-pocket corporations. 

I urge you to raise your voice against 
Amazon and other companies who use 
our overwhelmed patent office to claim 
ownership of well-understood and wide- 
ly used techniques. Tim O'Reilly (presi- 
dent and CEO of computer book pub- 
lisher O'Reilly & Associates) posted an 
excellent open letter to Amazon CEO 
Jeff Bezos, which you can read and add 
your name to at http://perl.oreilly.com/ 
cgi-bin/amazon_patent. comments. pi. I 
urge you to lodge your protest against 
Amazon, and also to hit the company 
where it really hurts: in the wallet. Buy 
merchandise elsewhere, and don't sell 
your games through the site. ■ 
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Maya 3 Announced 

ALIASIWAVEFRONT has announced the 
fifth major release of its Maya 3D ani- 
mation and visual effects software. 
Maya 3 includes a new feature called 
Trax, designed to benefit game artists 
who need to edit large amounts of 
motion capture data or mix together 
multiple animation sequences of the 
same character in a nondestructive, 
hierarchical; and time-independent 
manner. Trax allows developers to 
manipulate and blend animation in a 
way that can be reproduced in final 
game play, allowing subtle changes to 
motion capture data while leaving the 
original data intact. 

In addition to Trax, other new fea- 
tures in Maya 3 include the full inte- 
gration of Maya's subdivision surface 
tools into the animation and rendering 
pipeline. Maya 3 also introduces a 
completely new polygonal architecture 
that is more efficient in terms of speed 



and memory, and capable of support- 
ing a much wider variety of polygonal 
topologies. A new Bezier surface editor 
provides full access to curved surface 
representation. 

Maya Complete 3 will be available 
this summer for IRIX and Windows 
NT. Prices are expected to start around 
$7,500. 

■ AliaslWavefront 

Toronto, Ontario, Canada 
(416) 362-9181 

http://www.aliaswavefront.com 



Nuendo for Postproduction 

STEINBERG released its Nuendo Media 
Production System, a modular system 
centered on an audio software applica- 
tion that integrates seamlessly with 
several software and hardware acces- 
sories. Nuendo is a 128-track audio 
recording facility and a complete 128- 
channel audio mixer, which supports 
surround sound in impressively flexi- 
ble ways. The system can be configured 
for any surround format, including 5.1 
and 7.1, and users can create their own 
setup or use a standard configuration 
from Nuendo's library. Nuendo features 
UD to 200 



New Products: Alias|Wavefront intro- 
duces Maya 3, Steinberg releases Nuen- 
do, and Animal Logic offers Renderman 
output to Max users, p. 7 

Industry Watch: Sony and Nintendo 
try to out-convenience each other in 
Japan, Connectix bests Sony in court, 
and Bonnell takes over at GT. p. 8 

Product Review: David Stripinis 
looks at two facial animation tools, 
Famous Technologies' Famousfaces and 
Lipsinc's Echo. p. 10 

function is run from the computer's 
host processor. 

Nuendo is available for Windows 98 
and NT, and Steinberg also plans to 
release a version for BeOS in the near 
future. Pricing for Nuendo starts at 
$1,295. 

■ Steinberg North America 
Cliatsworth, Calif. 
(818) 678-5100 
http://www.us.steinberg.net 



Animal Logic s Naxman Plug-in 

ANIMAL LOGIC has created Maxman, a 
plug-in that allows 3D Studio Max 
users to output their content directly 
to Pixar's Renderman package as a ren- 
dering alternative. 

Maxman produces a Renderman 
.RIB file from a 3D Studio Max scene 
while preserving all geometry, anima- 
tion, and texture data and allowing 
the assignment of Renderman shaders. 
The Maxman suite of fully integrated 
and interactive plug-ins includes a 
top-level interface for 3D Studio Max, 
a set of modifiers, and materials and 
maps with which Renderman users 
can manipulate the finer details of the 
.RIB creation sent to Renderman. 
Maxman integrates into 3D Studio 
Max using standard scene controls. 
Renderman shaders are supported in 
all contexts, including global atmos- 
phere, light, displacement, volume, 
and surface, with full integration of 
their parameters into the Max anima- 
tion system. 

Maxman can be used with Pixar's 
Renderman Toolkit, BMRT, or other 
Renderman-compliant renderers, and 
support for RenderDotC is forthcom- 
ing. User licenses for the full version 
start at $2,000 for Windows NT 4 and 
3D Studio Max 3.1. 
■ Animal Logic 

Sydney, Australia 

+61 (2) 9383-4800 

http://www.animallogic.com 




tracks of 24- 
bit, 96KHz 
digital audio, 
advanced sur- 
round mix- 
ing, a video 
track, and 
MIDI tracks, 
along with 
comprehen- 
sive functions 
for digital 
audio. Nuen- 
do uses exclu- 
sively native 
signal pro- 
cessing with 
no DSP chips 
needed. Every 



The Nuendo Media Production System tiarnesses ttie power of 
your tiost processor, eliminating the need for DSP chips. 
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Industry Watch 



bif Daniel Hwebner 

FINAL FANTASY VIII AND SOME BEEF 
JERKY, PLEASE. Both Sony and Nin- 
tendo have made moves to place their 
products in Japan's ubiquitous corner 
stores. Playstation.com, Sony's online 
hardware and software sales site, counts 
7-Eleven of Japan among its group of 
1 1 investing companies, giving Sony 
sales and distribution access to 7- 
Eleven's 8,000 retail locations across 
Japan. Nintendo matched the move by 
purchasing a three-percent stake in 
Japanese convenience retailer Lawson, 
granting Nintendo access to 7,000 
Lawson outlets. Both arrangements will 
include on-site sales of hardware and 
software and the option for Japanese 
customers to pay for and take delivery 
of products ordered online. 

GRAPHICS WARS RAGE ON. Leading 
contenders in the hardware accelera- 
tion wars ended the fiscal millennium 
on decidedly different notes. Nvidia's 
fourth quarter revenues increased 96 
percent to $128.5 million from fourth- 
quarter totals a year earlier. Net 
income for the quarter doubled the 
previous year's result, increasing to a 
company record of $14.6 million. For 
the entire fiscal year, revenues rose 
137 percent to $374.5 million, while 
net income for the year increased 822 
percent to $38.1 million. The numbers 
posted by 3dfx were less rosy. Though 
3dfx's fourth-quarter revenues rose 
this year from $60.7 million in the 
fourth quarter last year to $109.4 mil- 
lion this year, the company recorded a 
quarterly loss of $31.9 million as 
opposed to a profit of $2.1 million in 
the same period a year ago. Revenues 
for the entire year of 1999 went up to 
$360.5 million compared with 1998's 
total of $202.6 million. Losses, howev- 
er, increased to an astounding $63.3 
million compared with earnings of 
$21.7 million in 1998. 

RECENT ACQUISITIONS. ATI Technolo- 
gies has entered into a definitive deal 
to acquire graphics chipmaker ArtX for 
approximately $400 million in ATI 
common shares and options. The 
acquisition helps move ATI into new 
consumer markets; in addition to 




developing graphics chips for DVD 
players and Internet terminals, ArtX is 
the provider of graphics technology 
for Nintendo's upcoming Dolphin 
console. ArtX founder Wei Yen has 
joined the ATI board of directors, cur- 
rent ArtX president Dave Orton took 
the newly-created title of president 
and COO of ATI Technologies, while 
ATI's K.Y. Ho will continue as CEO and 
chairman. 

Electronic Arts went on a buying 
spree of its own, buying game maker 
Dreamworks Interactive. Under the 
terms of the agreement, Dreamworks 
Interactive will become a wholly- 
owned subsidiary of Electronic Arts 
while continuing to produce titles 
related to Dreamworks SKG properties. 
The company, originally founded as 
joint venture between Dreamworks 
SKG and Microsoft, has been publish- 
ing with EA for the past two years. 
Terms of the sale were not disclosed. 

UNDER NEW MANAGEMENT. Info- 
grames chairman and CEO Bruno Bon- 
nell has taken up the reins at GT Inter- 
active as chairman and CEO. Bonnell is 
filling the positions left vacant by the 
departures of GT CEO Thomas Hey- 
mann and COO John Baker. Los 
Angeles-based Heymann and Baker 
both decided to leave in part because 
of the company's decision to remain 
headquartered in New York. 

The moves follow Infogrames' acqui- 
sition of a 70 percent stake in GT, and 
could signal the start of Bonnell's efforts 
to merge the two companies. GT Inter- 
active's third-quarter results were short 
on bright spots as the company 
announced net losses of $118 million 
for the quarter, while revenues slipped 
to just $102 million. Though GT blames 
the quarter's slump on a light release 



schedule, as much as $89 million of the 
quarter's loss can be attributed to 
charges incurred from restructuring and 
reorganization related to the acquisi- 
tion. GT's reorganization includes an 
end to its European operation, folding 
its budget publishing business, and the 
closure of Total Annihilation developer 
Cavedog Entertainment. 

CONNECTIX WINS APPEAL. Playstation 
emulator maker Connectix has won 
the reversal and remand of a court 
injunction banning the sale of its Vir- 
tual Game Station for Macintosh. Sony 
had contended that the Virtual Game 
Station infringed on Sony copyrights, 
especially in relation to the Playstation 
BIOS (basic input/output system), and 
tarnished the Playstation reputation. 
Connectix, backed by software makers 
and trade associations, argued that 
they had the right to replicate non- 
copyrightable functional elements 
including a reverse-engineered BIOS. 
The court agreed, and recognized Con- 
nectix as a legitimate and innovative 
competitor. Connectix plans to begin 
shipping the Macintosh Virtual Game 
Station immediately and a Windows 
version soon after, u 
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PC Data Trends 2000 

THE W HOTEL 

San Francisco, Calif. 
June 8-9, 2000 
Cost: early-bird rates available 
http://www.pcdata.com/ 
conferences 



NedPi Software 2000 

CONGRESS CENTER AND 
AUDITORIUM MONACO 

Monte Carlo, Monaco 
June 28-30, 2000 
Cost: variable 

http://www.unmf.fr/anglais/ 
home-a.html 
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Facial Animation 
with Echo and 
Famousfaces 

Until recently, facial animation 
wasn't an issue in game produc- 
tion outside of prerendered 
cutscenes. Memory limitations prevent- 
ed large-scale facial animation, while 
polygon budgets often kept characters 
from even having lips, never mind lip- 
synched dialogue. The advent of next- 
generation platforms like Sony's Play- 
station 2 and Nintendo's Dolphin 
promise capabilities that will make 
these limitations nearly immaterial. The 
downside of this is that as producers 
and designers begin to promise publish- 
ers hours of detailed facial animation, 
the animators sit in abject horror. While 
the thought of doing hours of facial ani- 
mation may appeal to some, the sheer 
scope of such a task sends many anima- 
tors running and screaming to the hills. 
As technical limitations evaporate, 
ambitions grow and production sched- 
ules shrink. Animators looking for 
viable solutions for streamlining this oft 
tedious process would do well to exam- 
ine two pieces of software: Echo from 
Lipsinc and Famous Technologies' 
Famousfaces. 

I ECHO works via voice 
'analysis. The user pro- 
vides audio files of dialogue, and Echo 
breaks the voice track into keyframe 
data and writes that data into a simple 
text file. This data can then be read 
directly by a game engine to provide 
on-the-fly animation data, or anima- 
tors can use it to hand-animate char- 
acters. 

INTERFACE. On first starting the pro- 
gram, you are presented with a very 
simple interface. A text window gives a 
status report of all options currently 
set, but not much else. The only way 
to change program options is by edit- 
ing the .INI file directly. While this 
may provide some with a sense of secu- 
rity that users will not mess up the 



« J. 




— > ' Ai±i-l ^ 



■ -I ■ A-l A li^ l-> I I— l-l ■-■ 

-■. r,m-, i#i.fc-i y-' i.h^' k*^ * 
■ 01.1 ,l.k n.^ .^rf--. It 

rtwi — ■ — " 



Echo's user interface. 



data coming out of 
Echo, I found it 
quite cumbersome. 
A simple Prefer- 
ences menu would 
have been wel- 
come. Once the 
options are set, 
however, using the 
program could not 
be easier. The user 
simply has to drag 
a selection of audio 
files onto the Echo 
window, and the 
analysis is done in 
a batch process. 
WORKFLOW. Output 

is provided as a text file with a .SYNC 
extension. There are three flavors of 
output: flipbook, dopesheet, and 
viseme curve. With both the flipbook 
and dopesheet options you can speci- 
fy either viseme or phoneme output. 
The viseme curve output is limited 
only to visemes. The program sup- 
ports 16 visemes and 41 phonemes, 
the choice of which is controlled in 
the .INI file. This may seem confusing 
to animators familiar with the "clas- 
sic" mouth shapes used for lip-synch- 
ing, which are commonly referred to 
as phonemes; in Echo, 'Viseme" is the 
comparable term. The 16 visemes are, 
by default, referred to by a rather con- 
fusing set of words that approximate 
the mouth shape of the viseme. The 
mapping can be changed in the .INI 
file, including mapping multiple 
shapes to a single shape. The larger set 
of phonemes provides a much more 
detailed analysis report, though that 
amount of detail is largely unneces- 
sary for most applications. 

The simplest of the three output 
options is the flipbook. It outputs a 
time index and a viseme name. The 
time, in milliseconds, indicates at what 
point from the beginning of the sound 
file a phoneme or viseme begins. It is 
the least complicated of all the output 
options, and is possibly the format 
most suited for direct use in real-time 
applications. 

For animators, a more familiar out- 
put option is the dopesheet. This for- 
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David Stripinis is director of animation at Factor 5. When not rambUng on about the 
sociopolitical ramifications of next-generation platforms, he can be found at his comput- 
er, desperately trying to finish his short film India. Contact him at david@factor5.com. 



mat is very similar to a traditional ani- 
mator's exposure sheet, listing frames 
and mouth shapes. If you have no way 
of automatically inputting the Echo 
output files into your software, the 
dopesheet format will most likely fill 
your needs quite well. 

The most robust output option of 
the three is the viseme curve, which 
lists every viseme, including detailed 
information for each key. It lists frame 
time, keyframe value in a percentage, 
and spline values in and out of that 
key. For ambitious animation systems, 
this data can be read directly into the 
real-time engine. This is also the most 
useful for reading into 3D animation 
software. 

If none of these options works for 
your application, Lipsinc does offer 
customization options. You can contact 
them for more details regarding your 
circumstances. 

Overall, I found the output from 
Echo to be very accurate, especially 
when using the optional text compan- 
ion files to remove all ambiguity as to 
what is being said. The analysis can be 
too accurate, in fact, providing too 
much detail and resulting in an overly 
busy animation. Echo also does not 
take into consideration any of the 
emotive qualities of the vocal perfor- 
mance, and cannot handle full facial 
animation, only lip-synching. 

_■■ r*"- '-^ Famous Technologies, 
offers a completely different approach. 
It is a stand-alone Windows NT appli- 
cation dedicated to facial animation 
and plug-ins for a variety of popular 
animation packages are also available. 
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Setting up clusters with Famousfaces. 



Famousfaces works by facial capture, a 
process very similar to motion capture. 
A performer's face is rigged with a 
number of reflective markers and 
videotaped. This data is then read in 
and tracked, producing the animation 
data while the voice recording is being 
done. Famousfaces supports both full 
3D point tracking and 2D image track- 
ing in the FamousTracker software that 
is included. 

INTERFACE. I was very pleasantly sur- 
prised by the Famousfaces interface 
when I first opened it up. It was very 
clean and would be familiar to any ani- 
mator working with the current gener- 
ation of 3D software. A main window 
holds the 3D viewport, the menu and 
command panels sit along the top and 
right side, and a time slider rests along 
the bottom. Navigation in the 3D 
viewport was very intuitive to me as a 
Maya user, using a combination of 
mouse clicks to pan, zoom, and rotate. 
Actually, it may have been a little too 
familiar, as I found myself getting frus- 
trated trying to use the Maya com- 
mands in Famousfaces. Too much of a 
good thing, I suppose. 
WORKFLOW. Famousfaces works by 
importing a model via a variety of 
object formats and applying clusters 
to the face. Clusters are collections of 
vertices controlled by a common 
point, influenced by the controlling 
cluster points by varying percentages. 
These clusters are quite intuitive to set 
up using a painting tool to control 
the weighting of each cluster point. 
These points are then driven by ani- 
mation channels derived from your 



captured data, and 
may be edited and 
tweaked using a 
familiar suite of 
keyframing tools. 
The software 
allows you to view 
the video of the 
capture session 
linked to your 
playback and time- 
slider scrubbing, 
giving you the 
ability to check 
the integrity and 
quality of your 
animation. 

One of the best 
features of 
Famousfaces is the 
Enabler plug-ins, which allow you to 
integrate Famousfaces into Maya, 3D 
Studio Max, Softimage, and Light- 
wave. Famousfaces integrates itself 
into each program's particular work- 
flow, for example running as a Maya 
Embedded Language (MEL) script in 
Maya while appearing as a modifier in 
3D Studio Max, allowing artists to go 
back and forth relatively seamlessly 
between Famousfaces and their soft- 
ware of choice. 

The quality of the animation pro- 
duced by Famousfaces, even using a 
simple 2D track of a video, is quite 
stunning. Even more impressive is the 
full 3D capture that can be achieved 
via multi-camera setups. I was really 
amazed by the subtlety of motion 
achieved in such a short period of 
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Lipsmc 

Gary, N.C. 
(919) 468-7005 
I http://www.lipsinc.com 

Price: Licenses start at $10,000. 

System Requirements: Windows 98/ NT 4, 
Pentium II, and 64MB RAM. 

Pros: 

1. Variety of output formats and customization. 
2.Simple to use, especially while batch 

processing. 
3. Very accurate analysis. 

I Cons: 

1. Only derives speech; emotion is left to the 
animator. 

2. Configuration options not easily accessible. 
Output can be too busy. 



time. I managed to set up the clusters, 
track the video, and apply the motion 
in a just few hours. After I familiarized 
myself more with the product, the 
process was even faster. 

The quality of data may be the 
major shortcoming of Famousfaces. It 
works by pure vertex deformation, not 
by using weighted morph targets. This 
means that in real-time applications a 
large amount of data must be streamed 
into the animation engine, which may 
cause some problems. 

Overall, I found Famousfaces to be 
quite viable in a production environ- 
ment. While it comes with all the bag- 
gage and hassles generally associated 
with motion capture, such as data 
management, animation data density, 
and the need for input hardware, the 
results are worth the hassle. Being able 
to create animation of this quality and 
detail with such speed and ease should 
be a welcome blessing to animators 
everywhere. 

GETTING A HANDLE ON YOUR WORKLOAD. 

Facial animation in games is here to 
stay and it will only get more complex 
as time, technology, and expectations 
move inexorably forward. Animators 
must find viable solutions to stream- 
line the process if they are to keep on 
schedule. Lipsinc and Famous Tech- 
nologies provide tools that help, 
though neither product has yet 
achieved perfection. In the end, I 
found both still required some massag- 
ing of data and an animator's skilled 
hand, but they were extremely helpful 
to the animation process. ■ 
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Famous Technologies 

San Francisco, Calif. 
(415) 835-9445 
http://www.famoustech.com 

Price: $4,990 

System Requirements: Suggested requirements 
include Windows NT, 330IVIHZ Pentium III, 
256MB RAM, and OpenGL acceleration. 

Pros: 

1. Highly detailed full facial animation. 

2. Intuitive interface. 

3. Easy integration with other 3D software. 
Cons: 

1. Cost of equipment for capture. 

2. Density of data. 

3. Facial animation can't be done until final 
dialogue is recorded. - 
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To Deceive is To Enchant: 
Programmable Animation 




hen we create a game, we create an illusionary world for the 
player. Hopefully this world is so rich and alive that the player 
may actually begin to believe in the existence of this game 
world. As game makers, we are in the business of creating life. 



Games are getting pretty good at cre- 
ating believable and immersive 3D 
game worlds. Graphics hardware has 
enabled multi-texture lighting tech- 
niques and higher polygon counts, 
greatly improving the environments 
where we play. It's not uncommon for 
a person passing by a computer moni- 
tor or television screen to mistake a 
game environment for a video broad- 
cast or a still photograph of some real 
place. 

There are few people, however, who 
would mistake a 3D animated character 
for a real person. In the early days of 
3D games, it was sometimes even hard 
to tell what a character was supposed 
to be. Now that computing power has 
enabled us to create more realistic- 
looking characters, we need to make 
these creations come alive. It is not 
enough that the character looks as 
good as a still rendering. Characters 
need to have what Frank Thomas and 
Ollie Johnston of Disney called ''the 
illusion of life." 



Creating the Illusion 



One of the great challenges that an 
animator faces is giving a model 
the appearance of life. Creating a walk 
cycle for a character where the feet 
move correctly and do not slide will 
not make it come to life. A good ani- 
mation will give the character a sense 
of weight, purpose, and emotion, 
attributes which must be individually 
crafted for each character. This is one 
of the pitfalls many encounter when 
using motion capture to generate ani- 
mation. It would seem that when cap- 



turing the performance of a live per- 
son, you would get all the subtle 
nuances that gives the person life. To 
some extent that's true. However, what 
you are capturing is the performance of 
an individual of a particular size and 
type operating under certain physical 
limitations. These limitations affect the 
range of reality the actor can impart on 
a character. 

An interesting example of this was a 
visual effects company that needed to 
create a superhero. They hired a very 
talented stuntman and attached him 
to various harnesses and had him 
leap, roll, pose, strut, and fight all 
over a stage while the performance- 
capture cameras were rolling. Unfor- 
tunately, when the motion was 
applied to the hero model, instead of 
looking like a superhero it looked like 
a guy hooked up to a harness jumping 
around. This is because the equipment 
accurately captured the performance 



of this person. He was an actor, not a 
superhero. He didn't move the way we 
expect a superhero to move, and the 
company ended up hiring a group of 
animators to bring this superhero to 
life. Sometimes even captured reality 
is not enough to make a work of art 
come to life. 



Uinkin\ Blinking and Nod 

One of the things that can kill the 
illusion of life very quickly is to 
have a dialogue with a character star- 
ing at you continuously without ever 
blinking. This is very distracting, as we 
are very obviously accustomed to talk- 
ing with people who blink occasional- 
ly. When this doesn't happen, it's 
immediately apparent that something 
is wrong. So, an easy step toward mak- 
ing your characters more realistic is to 
allow them to blink. 




FIGURE 1 . Programming a blinking animation can add realism to a ctiaracter. 



Jeff is becoming more and more concerned about what procedural functions are con- 
trolling his thoughts. If you are the one actually in control, drop him a line and let 
him know what is really going on at jeffl@darwin3d.com. 
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FIGURE 2. People tend to look 
around their surroundings when idle. 



In a low-polygon model, there may 
not be polygons allocated to the eyes 
that would make a blink possible. In 
this case, it's possible to use texture 
animation to make a blink happen. 
This has been done in a few 3D games 
(Grim Fandango, for example). How- 
ever, if I really want to create expres- 
sive characters that can show a range of 
emotions, I need a model with enough 
facial polygons to convey the expres- 
sions I want. I could hand-manipulate 
the eyes throughout all of my anima- 
tions, including an idle cycle. But this 
would mean the blinks would always 
happen at the same time in the cycle 
and it may look canned. Why not ani- 
mate the eyes automatically through 
the game engine? 

If you read my column on real-time 
facial animation (''Flex Your Facial 
Animation Muscles," Graphic Con- 
tent, July 1999), you may remember 
that I advocated creating a series of 
facial morph targets that simulated 
the actions of the facial muscles. In 
this system, there is one muscle that 
controls the closing of each eye. By 
activating these two muscles, I can 
make my character blink whenever I 
want. It may seem overkill to have 
each eye individually controlled 
instead of having one action that clos- 
es both eyes. However, if you want the 
character to have the ability to wink, 
you will need this flexibility. I also 
don't really care for synchronized 
blinks. There are arguments over this 
among animators, but I happen to 
prefer it if the eyes do not close at the 
exact same time. I like the eyes to 



close just off a half-frame or so. Creat- 
ing my models with separate muscle 
targets gives me this flexibility. 

Anyway, assume I have a model with 
individual muscle targets for closing 
the left and right eye. The muscle set- 
tings go from percent (open) to 100 
percent (closed). I know that I general- 
ly want the blinks to happen every four 
to ten seconds and each blink should 
take only two to three frames to com- 
plete. This gives me the outline for a 
procedural blinking model: 

1. Pick a random number from 90 to 
300 that signifies the number of 
frames until the blink begins 
(three to ten seconds at 30FPS). 

2. Every frame, count that number 
down until it hits 0. 

3. Pick a random number from 30 to 
50 for each eye. 

4. Add that number to each eye mus- 
cle, limiting to 100 percent. 

5. Subtract that number from each 
eye to get back to 0. 

6. Start over at step 1. 

You can see a sample blink sequence in 
Figure 1. 

This procedural sequence can run as 
part of my animation loop without any 
other controller. As the actual morph- 
ing system is part of the standard facial 
animation system, the blinking gener- 
ates very little overhead. 

This idea of a procedural function for 
generating motion can go beyond sim- 
ple blinking. When people are standing 



idle, their attention drifts. They look 
around to get a sense of the surround- 
ing environment. Likewise, a character 
in a game should not stare rigidly for- 
ward waiting for input from the player. 
If your facial controller allows you to 
orient the eyes, you can apply the same 
techniques as the blink function to 
make the character look around a little. 
Obviously, if the character is actually 
looking at an object or a person, this 
look-at constraint would override the 
random eye-wandering behavior. Simi- 



lar random facial effects can easily be 
crafted to move the eyebrows and 
mouth slightly, giving the character 
even more life. 

The game AI can also drive the char- 
acter animation system automatically. 
For example, the AI system may track 
many of the character's various attrib- 
utes such as fatigue level, mood, and 
physical pain. Facial expressions can be 
crafted to exhibit these various traits 
automatically as the AI system changes 
them. This not only adds realism to the 
game, it provides a secondary feedback 
mechanism to the player. 



Lookina Bevond the Face 

While simple facial adjustments 
can do a great deal to break a 
character's wooden stare, something 
needs to be done with the static poses. 
An idle animation or two can help a 
great deal. However, these animations 
are usually cyclical and the pattern is 
easy for players to detect. Adding some 
procedural noise to these standard ani- 
mations can help a lot. If your anima- 
tion system is composed of a character 
that is deformed by the use of a skeletal 
system, these kinds of on-the-fly modi- 
fications are easy to implement. For 
one thing, you could add a little ran- 
dom rotation to the head joint to 
match the wandering gaze of the pro- 
cedural eye controller. If there is a bone 



controlling the finger rotation, the 
character's grip can be relaxed and 
tightened, which people often do 
when they are waiting around for 
something to happen. 

I have often found it useful to create 
special bones in the character skeleton 
specifically for these sorts of custom 
procedural effects. One example is lit- 
erally breathing life into a game char- 
acter. In my column on skeletal defor- 
mation techniques (''Over My Dead, 
Polygonal Body," Graphic Content, 



A character in a game should not 
stare rigidly forward waiting 
for input from the player. 
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FIGURE 3 . Trust me, this chest is heaving. Adding a breath- 
ing sequence can enhance a character's emotional response. 



October 1999), I discussed the use of a full transformation 
matrix to deform a 3D character. A side benefit of this tech- 
nique is the ability to use transformation components 
beyond simple rotation. A bone can also be translated and 
scaled to deform the character. Though it may not be obvi- 
ous when these techniques are useful, this is one of those 
cases. Suppose I made a child bone of the chest and called it 
''breastbone." I could then attach the vertices at the front of 
the chest to this bone. By cyclically scaling this bone up 
and down, I can give the character the appearance of 
breathing. Say my character normally breathes 12 times a 
minute and this goes up to 20 times a minute when the 
character is very excited or fatigued. I can create a simple 
procedural formula that will automatically create a breath 
cycle in the game without using any animation. Something 
like breastbone. scale = (sin(DEG2RAD(fratne * 1.2)) / 4.0) + 1.25 
will make the breastbone scale up from 1 to 1.5 once every 
150 frames, or 12 times a minute at 30FPS. Increase that 1.2 
to 2 and the character would breathe 20 times a minute. 
You can see how formulas can easily be crafted that would 
enable all kinds of automated behavior. 

Ken Perlin has experimented more than most with using 
procedural functions and controlled noise to generate ani- 
mation. The Improv animation system, developed at New 
York University's Media Research Lab and since licensed to 
Improv Technologies, uses controlled noise and a variety of 
animation blending functions to create unique and believ- 
able animation. The animation is controlled from a high 
level using a scripting language. You can see a Java interface 
to an Improv-driven facial animation performance in Figure 
4. Improv Technologies is licensing its animation system for 
game development applications. 



Muscles Flexing 



A procedural noise or cyclical animation effect can be 
very interesting. However, sometimes an effect needs to 
be the direct result of an action. For example, a strong char- 
acter may have biceps that bulge as the character bends its 
elbows. Just as I did with the breathing example above, I can 




FIGURE 4 . Improv Technologies' system uses animation 
blending functions and controlled noise for unique effects. 



create a child bone of the upper arm and place it in the mid- 
dle of where I desire the biceps ''muscle" to appear. This log- 
ical bone for the biceps is then associated with the vertices 
along the top of the upper arm, exactly where the biceps 
would appear. I just need to scale the biceps bone up a bit to 
make the muscle bulge. In order to detect when I want this 
to happen, I could watch the rotation of the forearm and 
adjust the biceps as the forearm rotates. However, I really do 
not want to create all this code to monitor the bones 
involved in these effects. I just want it to happen automati- 
cally. 

In many 3D animation packages, you can create a struc- 
ture called an ''expression." An expression creates a mathe- 
matical link between two objects in the animation system. I 
want to use this same idea to simplify my muscle-bulge situ- 
ation. When the lower arm rotates around 120 degrees about 
its local X-axis, I want the biceps to be scaled up to 1.5 of 
their original size. An expression that performs this task may 
look like bicep. scale = (forearm. rotX / 240.0) + 1.0. 

As you can see, if the forearm is not rotated, the scale 
would be one. When the bone rotates, the scale will 
increase. Extra care needs to be taken to make sure that the 
scale doesn't go below one or get too great. However, this is 
easy to accomplish with degree-of-freedom restrictions. 

Effects similar to this can be achieved simply by animat- 
ing the biceps directly along with the forearm. Unfortu- 
nately, this will not work if the player can dynamically 
pose the character through inverse or forward kinematics. 
The use of expressions also saves animation space by elimi- 
nating the need to store the data directly. And while this is 
just a simple example, you can see that using expressions 
to generate real-time animation data can be a very power- 
ful tool. 



Looking Around the Room 

I any algorithmic techniques for animation cannot be 
I triggered simply by a mathematical expression or sto- 
chastic procedure. They require some input from the user. A 
simple example is the look-at constraint. When the player 
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(or AI system) directs a character to 
look at a location, this direction takes 
the form of a request for an animation 
solution that solves a geometry prob- 
lem. Given a character who has a head 
that can look at a limited subspace, we 
need to find the orientation for that 
head that points in the direction of a 
target location. 

Recall that a 3x3 orientation matrix 
is composed of three orthogonal unit 
vectors that define the local coordinate 
axes of the rigid body. These vectors 
are often known as the right (R), up 
(U), and forward (F) vectors which 
define the local and Z-axes in 

the right body. If I can determine the 
direction for these three vectors, I can 
combine them to form the orientation 
matrix for the head of my character. 



Orientation = 



When the character looks at a loca- 
tion, the head is aligning one of these 
three axes with the vector between the 
root of the head and the look-at target. 
In my case, I have constructed the head 
such that it normally looks down the 
positive Z-axis. So to make the head 
look at something, I create a vector 
between the root and the target and 
normalize it so it becomes a unit vector. 
This defines the forward vector in the 
above matrix, giving me one piece of 
the puzzle. I know that generally I still 
want the head to be aligned upright 
along the original Y-axis. So for now, I 
am going to set the U vector to be 
(0,1,0). This may not be correct (the 
look-at may cause the head to tilt a bit), 
but for now it will be fine. 

To determine the R vector, I am 
going to use the fact that the cross 

Disney Animation 

Thomas, Frank, and OUie Johnston. The 
Illusion of Life: Disney Animation. New 
York: Hyperion Press, 1995. 

Improv Technologies 

For information on Improv see Ken 
Perlin's web site as well as Improv 
Technologies'. 
http://www.kenperlin.com 
http://www.improv-tech.com 



product of two vec- 
tors is perpendicular 
to them. 

R = UxF 
But I still need to fix 
up U since my guess 
may not have been 
correct. This is easi- 
ly accomplished by 
crossing the F vec- 
tor with the new R 
to determine the 
actual U vector. 
U = FxR 
That gives me all 
the pieces to the 
orientation matrix 
and I can make the 
head look at any 

point in my 3D world. However, this 
could lead to problems if the point is 
behind the character. The head would 
spin around like Linda Blair's in The 
Exorcist. In most cases, you will want 
to have limits on look-at constraints so 
the characters will only do what is 
physically possible. For the head, I 
probably want to restrict the character 
so it can turn its head only 60 degrees 
or so in each direction. In order to 
make this happen using the above 
method, I would need to take the ori- 
entation matrix I calculated and con- 
vert it to Euler angles and make sure 
none of the angles was outside the 
range of plus or minus 60 degrees. 
That is kind of a pain and mathemati- 
cally intensive so let's take a look at 
the problem in another way. 

From a geometric perspective, the 
problem of looking at an object can be 
thought of as a two-degrees-of-freedom 
problem. I want to find the angle 
around the local Y-axis (or yaw) and 
the angle around the local X-axis (or 
pitch) that the head needs to rotate in 
order to look at the target. I can solve 
the problem by projecting the target 
point onto the local XZ plane to deter- 
mine the yaw, then projecting the tar- 
get on the local YZ plane to determine 
the pitch. Each of these steps then 
becomes very easy. Figure 5 shows the 
target position projected onto the XZ 
plane. 

I know from trigonometry that the 
value for tanO is equal to TJT^. So I can 
determine what yaw the head needs to 
turn by taking atan(T^/T^). I can do the 
same for the pitch using atan(T^/T^). If 
those values are within the range of 




FIGURE 5 . Projecting the target position. 



motion for the head, the character can 
animate to that position. 

The Rise of the 
Programmer/Animator 

■ think we are quite a ways from 
being able to create complete, 
believable, and interesting animations 
programmatically for interactive 3D 
characters. But an interactive charac- 
ter is not like an actor in a video clip 
or a 3D cutscene movie. In order for 
this character to create the illusion of 
life while the player interacts with it, 
we need to accentuate the 3D model 
with programmable animation tech- 
niques. Through creative use of meth- 
ods such as procedural animation and 
programmable expressions, we can 
supplement the basic animation with 
interactive elements that react with 
the game environment. In this 
respect, game developers are clearly 
treading across new ground. These 
challenges and opportunities are 
unique to interactive animation. How- 
ever, this is certainly not the domain 
of game programmers alone. Creating 
tools and production procedures that 
can get artists, with their creative 
vision for the game characters, 
involved in the process will be critical 
if we are to deceive and enchant our 
audience successfully. ■ 
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Skin Deep 3: Animating and 
Texturing a Patch Surface 



or the past two months, we Ve been examining some of the latest and 
greatest surfacing strategies for real-time 3D content. The motivation for 
this has been the fact that as the rendering and processing power of gam- 
ing platforms increases, the amount and complexity of gaming content 



will, in general, rise to take advantage 
of the increased capability. In order to 
accommodate this increased capability, 
we have presumed that a shift in pro- 
duction techniques is now or will soon 
be appropriate, so that we as artists will 
be able to plan for and take advantage 
of this increased horsepower. 

Of all the surfacing methods we've 
examined, I identified the B-spline 
patch surface to be one of the most 
effective, and last month we took a 
look under the hood at how to con- 
struct and implement a RT3D patch 
surface model using 3D Studio Max. 
Since it's unlikely that your job as an 
artist ends there, we'll round out our 
discussion of surfacing techniques this 
month by examining texturing and 
animation methods for our B-spline 
patch surfaces. 

Task Breakdown: 

Modeling, Texturing, Animating 

In last month's column, I demon- 
strated the advantages, from a mod- 
eling standpoint, of using a B-spline 
patch. Following the guidelines of our 
predetermined ideal process (that is, 
using a control point lattice to sepa- 
rate the modeling process from the 
complexity of the final result, as 
shown in Figure 1), we were able to use 
the surfacing tools in 3D Studio Max 
to create a resolution-independent 
RT3D character model. And since the 
technique we used was totally resolu- 
tion-independent, we could scale the 
complexity of the model instanta- 
neously to generate an arbitrary num- 
ber of levels of detail. The example 



character we generated took only a few 
days to create. By contrast, to arrive at 
the same result using standard polygo- 
nal methods would have required sev- 
eral additional days' worth of model- 
ing time. 

Though significant, the time saved 
in generating the character geometry is 
only one of the benefits of using a sur- 
facing technique. The task of modeling 
a character is by far the smallest and 



Polygonal Method 



least time-consuming part of the char- 
acter creation process. The texturing 
and animation setup for the character 
can take anywhere from two to five 
times the amount of time spent in 
modeling the geometry. And, using 
standard polygonal methods, the time 
and effort spent in texturing and ani- 
mation setup is directly proportional 
to the complexity of the geometry. In 
other words, the more complex the 



Surfacing Method 
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FIGURE 1. Control point methodology. 
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character model, the longer it takes to 
apply the mapping coordinates and 
weight the character to its skeletal 
hierarchy. In order for our chosen sur- 
facing technique to be valid, we need 
to make sure that the efficiency and 
cost savings we saw in the modeling 
tasks are fully realized in the texturing 
and animation setup for the character 
as well. 



Texture Napping 



Among the various production 
tools, the processes for applying 
a texture to 3D geometry are reason- 
ably uniform. In general, a pregenerat- 
ed texture map is applied first using a 
global mapping object (planar, cylin- 
drical, spherical, and so on), and sub- 
sequent local modifications to vertex 
UV coordinates are made by manipu- 
lating the points on a 2D projection of 
the geometry, as seen in Figure 2. 
Although there have been some 
advances with procedural textures and 
spatial coordinate field mapping, the 



steps and procedures for applying tex- 
tures follow these basic guidelines. 
And since the global mapping objects 
offer only gross control over the UV 
coordinates of the geometry, much of 
the time and effort spent texturing the 
model is used to tweak the local coor- 
dinates directly, using one of the vari- 
ous unwrapping tools available. So the 
more vertices an object contains, the 
more UV coordinates need to be 
stored and manipulated, and the 
longer it will take to apply and adjust 
the texture mapping. Until the basic 
techniques for texturing are changed, 
the time and effort spent texturing 
will be directly linked to the complex- 
ity of the content. By implementing a 
surfacing technique like our ideal 
process (Figure 1), we can break this 
link between complexity and textur- 
ing time. 

Figure 2 shows the same texture 
map applied to two similar geome- 
tries. At the top is a relatively high- 
resolution polygonal mesh and its cor- 
responding representation in the local 
mapping tool (UVW Unwrap). Note 





the excessively high number of UV 
coordinate points, corresponding to 
the number of vertices in the mesh. 
It's clear that any local manipulation 
of the mesh's UV coordinates will be a 
difficult and tedious process. Compare 
this with an equivalent surface created 
with patches, shown at bottom. 
Regardless of the resolution and num- 
ber of patch subdivisions, the artist 
need only work with the control point 
lattice when it comes to mapping. Not 
only will the artist spend less time on 
the mapping process, but the result 
will be exact, since the UV coordinates 
are smoothly interpolated along each 
patch boundary when the model sub- 
divides procedurally. Furthermore, 
once the control point lattice is tex- 
tured, any number of LODs can be 
generated instantly, whereas with the 
polygonal mesh each LOD must be 
texture-mapped by hand. 



Animation Setup 



FIGURE 2 . The Unwrap modifier in Max, comparing the high-resolution polygonal 
map (top) with an equivalent surface created with patches (bottom). 



As is the case with the texturing 
process, the tools and techniques 
for setting up a character to be animat- 
ed using a weighted skeletal hierarchy 
are fairly consistent between produc- 
tion packages. The process is achieved 
in two steps: first the animator applies 
a skinning modifier to associate the 
geometry globally with a pregenerated 
skeletal hierarchy (bipedal hierarchies 
now come ready-made in most pack- 
ages), and then modifies the weighting 
values by hand to ensure proper defor- 
mation of the animated skin. Similar to 
the texturing process, the initial global 
skinning process is seldom accurate 
enough, and much of the time in ani- 
mation setup is spent making minute 
adjustments to the vertex weights to 
ensure that the skinned geometry 
deforms properly. 

The tools for adjusting the weights 
are fairly advanced, and include the 
ability to paint the weights directly on 
the surface of the geometry or to 
adjust a ''bounding envelope" graphi- 
cally, which is associated with a spe- 
cific hierarchical node. However, the 
number of vertices or control points 
in the weighted geometry remains the 
limiting factor in time and effective- 
ness. This is even more important 
than in the texturing step: with a 
polygonal mesh, as the complexity of 



GAME DEVELOPER MAY2000 



http://www.gdmag.com 



ART I ST ^ S VIEW 




FIGURE 3 . Comparing the number of skeletal envelopes and vertices between a 
patch-based leg and boot with weighting applied (left) and a polygonal one (right). 



the model increases, so too does the 
number of vertices which may be 
slightly off in their weighting values, 
which when animated can create a 
host of visible kinks and tears in the 
surface. 

Removing or preventing these 
weighting errors and creating a smooth- 
ly contiguous animating surface is the 
primary goal of the animation setup 
process. Clearly, when using standard 
polygonal methods the animator's 
effort and effectiveness are linked direct- 
ly to the model's complexity. In order to 
produce good, quick results, we again 
need to sever this link between the ani- 
mator and the complexity of the data. A 
visual representation of how this occurs 
can be seen in Figure 3. In the example 
on the right, a fairly detailed polygonal 
mesh has been weighted to a skeletal 
system. The skeletal envelopes and ver- 
tices of the mesh are clearly visible. An 
animator tasked with setting up this 
mesh has a long day ahead of him. On 
the left, we see a patch-based model of 
equivalent complexity. The number and 
density of the polygons present at run 
time are identical, yet the number of 
vertices the animator has to weight is 
substantially less. As a result, there will 
be fewer potentially errant vertices, and 
subsequently fewer total errors to cor- 
rect and troubleshoot. 



Just as with the texturing process, in 
a standard polygonal implementation 
each and every LOD generated needs to 
go through a similar setup process. 
With a control point lattice implemen- 
tation such as 
patch surfaces, the 
process need only 
be executed once, 
and the higher- 
level LODs can be 
derived instanta- 
neously from the 
original surface 
simply by increas- 
ing the number of 
subdivisions. 

One additional 
advantage of 
B-spline patch sur- 
faces specific to 3D 
Studio Max 3 is 
that the control 
point handles can 
be given weighting 
values indepen- 
dent of the control 
points to which 
they are associated. 
This gives the ani- 
mator an addition- 
al layer of controls 
over the deforma- 
tion process and. 



when successfully implemented, can 
enable the animator to simulate com- 
plex surface behaviors such as muscle 
and cloth deformation. Figure 4 shows 
an example of this. On the left, the 
control point handles have all been 
weighted the same as their respective 
control points. On the right, the han- 
dles have been weighted differentially 
so that when the joint flexes, the sur- 
face simulates a muscle bulge. 

Taken in combination with the time 
saved actually modeling the geometry, 
the additional benefits in texturing 
and animation add up to a significant 
production cost savings. To quantify 
this. Figure 5 shows how the two 
approaches might compare in a real- 
world art path. Clearly, the cost sav- 
ings associated with such a surfacing 
strategy are well worth the time 
invested in adjusting to the new tech- 
nique. In contrast with the standard 
polygonal mesh approach, the control 
point lattice method has the potential 
to minimize production effort while 
maximizing the fidelity of the final 
result. The patch method can unfetter 
you from the burden of content com- 
plexity, allowing you to focus your 
efforts instead on the more creative 
aspects of your craft. 




FIGURE 4 . An example of control handle weighting. 
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Be Fruitful and Subdivide 

This wraps up our discus- 
sion of surfacing tech- 
niques, though we may even- 
tually pick it up again as the 
next generation of tools 
becomes available to us. It's 
interesting that as artists our 
primary motivation for 
exploring these surfacing 
techniques is related directly 
to issues of content produc- 
tion — that is, development 
time and cost. As such, it 
hasn't been necessary to 
focus on how these surfacing 
techniques can benefit from 
an application which has been 
optimized for nonpolygonal 
rendering. Clearly though, 
this is the direction in which 
the technology is headed. 

The benefits of using a pro- 
cedural subdivision technique 
are manifold, generating huge 
cost savings in transform and 
calculation speeds as well as 
data compression and render- 
ing speed. For example, in an 
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FIGURE ^. A snapshot schedule showing the time saved 


using the patch surface method compared with the tradition- 


al polygonal method. 







engine optimized for render- 
ing patch surfaces, the data 
(geometry, texture coordi- 
nates, weighting information, 
and so on) sent to the engine 
can be kept at its lowest reso- 
lution, giving the engine the 
ability to subdivide the surface 
only as necessary. Further- 
more, because all of the neces- 
sary information required to 
describe the surface exists 
within the low-resolution con- 
trol point lattice, the trans- 
forming and lighting calcula- 
tions can be executed before 
the surface is subdivided, dras- 
tically reducing the processing 
power required to render the 
complex surface. This trans- 
lates directly to faster render- 
ing and more efficient data 
storage, which to an a artist, is 
the equivalent of an almost 
unlimited canvas. ■ 
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W ^ cated medium, game characters are also experiencing a 

considerable metamorphosis. Just a few years ago, a game character had 



to be simple enough so that it could be represented clearly under very 




severe artistic limitations. Essentially, 
game characters were just icans, amar- 
phaus blabs, or tiny men rendered from a 
handful af pixels. But steady technalagical 
progress has slawly opened up passibili- 
ties for more believable and realistic 
characters. The question new is, hew 
dees a game developer leverage all of 
these additional technical resources to 
create more compelling characters!^ 
This article attempts to set out the ele- 
ments of design that need to be 

addressed in order to create 
a memorable and power- 
ful game character. ^ 




TOSy started working in the games industry in ^S)S>4■ at Core 

Design in Derby. While at Core, he conceived the game TOMB RAIDER and 
its main charocfer, Laro Croft. Toby was both the designer and lead artist on 
the project. His roles covered everything from story development, storyboard- 
ing, FMV generation, In-game animation, character design and modeling, level 
flow, title and load screens, box art and marketing/PR materials, in 12'2'7, hav- 
ing left Core Design, he set up Confounding Factor with business partner and 
lead programmer of the original TOMB RAIDER, Paul Douglas. Confounding 
Factor Is currently producing the game Calleon due for release this 
Christmas. 
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The greatest genre for 
characterization has always 
been the adventure game. 
Early Infogrames classics like 
Planetfall and LucasArts' 
later adventures such as Full 
Throttle showed how effec- 
tive ''game actors" could be. 
These characters used spo- 
ken dialogue and were por- 
trayed with emotional per- 
sonalities. Now these game 
actors are moving into new 
cross-genre 3D games, and it 
is here that they really 
thrive. In fact, they may be 
becoming a little too suc- 
cessful; we're beginning to 
see games sold purely on the 
strength of these characters. 
Worse still; it seems that 
characters today are inserted 
into games that simply don't 
require them, perhaps because it is now 
seen as a marketing necessity. 

The single most important rule in 
character design is ''the game comes 
first." The type of game you're develop- 
ing will determine most of your charac- 
ter-creation decisions. A character is 
just a tiny element of any game, and in 
many cases, it is a superfluous element. 
If a game works without a character, it 
shouldn't have one. The rules of ele- 
gance apply — look for the clearest, 
simplest way to represent an idea. 

Character Identification 

You can split games broadly into 
two groups: those with a first- 
person point of view (POV), and those 
with a third-person POV. Although 
that difference between them may 
seem slight, it is absolutely fundamen- 
tal, as the psychology of the two POVs 
is drastically different. 

A first-person game invites players to 
immerse themselves in the game, to 
play as though they themselves are in 
the game experiencing the events first- 
hand. On the other hand, the third- 
person game makes a distinction 
between the player and the on-screen 
character; they are separate entities. In 
a third-person game, the player is con- 
trolling a character rather than becom- 
ing the character. 

This difference utterly splits charac- 
ter design into two entities that I will 





FIGURE 1 . There is a fundamental difference between a first 
person ctiaracter and a ttiird-person character. 



refer to as the "Avatar" and the 
"Actor." The Avatar is simply a 
visual representation of the 
player's presence within 
the game world. The Actor 
is a character distinct from 
the player, with its own 
personality, characteristics, 
and, to some extent, mind 
(Figure 1). 

For example, let's look at 
Lara Croft vs. Duke Nukem. 
Although some projection always 
occurs in games, when you play 
Tomb Raider, it is Lara, not 
you, who gets eaten by the 
Tyrannosaurus rex and goes 
around shooting animals. 
When you play Duke Nukem 
though, even though Duke 
shows a personality, it's you 
who gets killed and you who 
goes around shooting things. 
Many games muddy this 
distinction and they 
lose a great deal of 
impact on players as 
a result. 

First- Person POV: The 
Avatar. A first-person 
game should make it 
as easy as possible for 
players to believe that 
it's actually them- 
selves in the game. 
The main character 
(the Avatar) must not 
interfere with the 




player's illusion of 
immersion. This means 
the Avatar shouldn't do 
anything with a mind of 
its own. For example, it 
shouldn't go around 
talking, and the game 
should never take con- 
trol away from the play- 
er under any circum- 
stances. From a design 
point of view, the Avatar 
is a cipher, an empty 
vessel waiting to be 
filled and given purpose 
by the player. 

There are two basic 
routes that you can go 
down when designing 
an Avatar. Either you 
create a deliberately 
insubstantial character, 
or better still, you allow 
players to create their own. This second 
method is even more valid when it 
comes to multiplayer games. 
In a first-person per- 
spective, many of the 
techniques of story- 
telling and characteriza- 
tion common to other 
mediums can't be used, 
simply because you 
don't really know what 
the main character, being 
completely controlled by 
the player, is going to do. 
Third-Person POV: The Actor 
The third-person POV allows far 
greater freedom to tell what is a 
more traditional story form. 
Because the character (the Actor) 
on the screen is a separate entity 
and dissociated from the player, 
it's not too disturbing when the 
Actor acts of its own accord in cer- 
tain situations. Even though this 
on-screen entity is controlled 
directly by the player, it is dis- 
tinct from the player's personali- 
ty, allowing the designer to 
imbue the Actor with a per- 
sonality of its own and occa- 
sionally control how it 
behaves. This extra element 
of control over the game 
makes it possible to use 
some of the less intrusive 
storytelling and mood- 
enhancing devices that 
have evolved in film. 
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Making an Actor 



From a design point of 
view, game characters 
can be sorted in order of 
design detail: 

• Avatar. These charac- 
ters require visual 
design only. 

• Actor. Full character 
design, but with a nec- 
essarily one-dimen- 
sional personality so 
that the player can 
flesh out its motiva- 
tions. The trick is to 
strike a balance 
between establishing 
the actor's personality 
without letting that personality 
disturb the player. 

• Non-player characters (NPCs). These 
require full character design. 

We all use very powerful subcon- 
scious mechanisms to judge people 
visually, whether we realize it or not. 
When you meet someone, the amount 
of information you gather from them 
using your eyes is incredible. You take 
into consideration their shape, height, 
sex, race, physical attractiveness, hair, 
clothing, makeup, cleanliness, facial 
hair, age, weight, stance, facial expres- 
sions, body language, movements, 
and so on. You perceive a vast amount 
of information almost instantly and 
without really trying. Your brain then 
begins to make assumptions about 
that person using built-in pattern- 
recognition techniques, most often 
based on your personal set of stereo- 
types. In contrast to these visual cues 
we pick up on, the slow linear stream 
of spoken information is incredibly 
small. After a while, our opinions may 
be re-formed based on a person's per- 
sonality, but for a long time it is still 
filtered through our preconceptions 
based on our first 
impression. So to ere- ^ 
ate a really good 
character, you have 
to control all of the 
visual clues that peo- 
ple use to judge each 
other and establish a 
clear, unified message 
to make players inter- 
ested in — and ulti- 
mately like — your 
character. 
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FIGURE 2 . N[uch of a character's design is determined by ttie deci- 
sions made about a game's environment and game play. 



could be achieved, most 
games would consist of 
overly complex, messy, 
and irrelevant details. 
Similar to cartoons, games 
use simplified representa- 
tions of real-world ideas, 
stripped of the massively 
complicated rules found in 
reality. Therefore, to make 
the greatest impact, we 
have to caricature; we 
must amplify the aspects 
we want players to focus 
on. This is the route to 
making games a more 
powerful medium. 



Style and Exaggeration 

In the early 1930s, Disney animators 
were struggling to bring the same 
depth of acting skills to their cartoon 
characters that actors were achieving in 
live-action films. Cartoons are a delib- 
erately simplified representation of 
reality, stripped of the incredibly com- 
plex subtleties we are accustomed to in 
the real world. These animators real- 
ized that they could never portray the 
same subtleties through animation, 
since the medium was too broad by 
nature. Instead, they exaggerated all 
the subtle body language and emotion- 
al expressions made by actors until 
they became almost a pantomime of 
good acting. Through exaggeration, 
cartoons are able to elicit very powerful 
emotional responses from an audience, 
because cartoon acting is a concentrat- 
ed version of live acting. 

Computer games are much more akin 
to cartoons than films. Games aren't 
very good at imitating reality, because 
elegance requires them to be visually 
limited. They can't mimic the incredibly 
complex world we live in. If such detail 




Ttie evolution of Micl<ey Mouse. 



The Three Linked Elements 

In a character-based game, there are 
three intrinsically linked elements: 
environment, game play, and charac- 
ter (Figure 2). 

A powerful character must be well 
adapted to its environment. Good 
characters typically have some ele- 
ment about them that makes them 
especially suited to their world. Take 
Indiana Jones, for example. Indiana 
hangs around all day in tombs and 
ancient sites that are filled with dan- 
gerous traps and angry natives. He is a 
tough, strong person, but more impor- 
tantly he is an archaeologist, and this 
is what makes him so well suited to his 
environment. From a character cre- 
ator's point of view, you would proba- 
bly come at this in reverse: the charac- 
ter is an archaeologist, so therefore his 
environment will be tombs and 
ancient sites. 

While the link between character 
and environment is true for noninter- 
active media as well as games, game 
developers must also consider an even 
more important factor: game play. 

Game play affects 
^ how an environment 
works. There is a link 
between what the 
player can do and 
what the environ- 
ment contains. 
Game-play decisions 
are also dictated by a 
character's special 
abilities, so game 
play and character 
design are linked. 
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too. Look at the character Bob in 
Shiny's Messiah. This little angelic 
character goes around and possesses 
people, and this attribute has massive 
game play significance, dictating exact- 
ly how his environment has to be pop- 
ulated and designed. Thus, as you 
change the attributes of any one of 
these three elements, the other two ele- 
ments are affected as well. 

Simply stated, the character design 
process cannot be isolated from the 
game design process. Many elements of 
a game character are completely decid- 
ed by game play and environment. 

Visual Design 

The visual design of a character can 
be split broadly into two aspects: 
physiological form and the clothes 
worn (if any). Physiological differences 
between one human and another are 
fairly slight; there is some variation in 
skin tone, size, hair, build, and weight. 
Gender is the only major variance, and 
apart from that I'm afraid all humans 
look alike to me. Clothing, however, 
varies greatly in color, shape, purpose, 
and significance. That is why costume 
design is so important. 

There has been a sudden surge of 
female main characters recently, which 
is good since it redresses the gender 
imbalance in our predominantly male 
industry. The choice of a char- 
acter's gender is critical, and 
not simply from a marketing 
perspective. (I won't talk about 
any aspect of character design 
from a marketing point of view 
since I don't think it is wise to 
approach any aspect of design 
from that angle. If you design a 
character to be liked by players, 
marketing opportunities will 
follow of their own accord.) 

A character must have digni- 
ty. Any design that objectifies 
the character (that is, encour- 
ages you to think of it as an 
object rather than a living 
being) will prevent players 
from empathizing with it and 
relating to it. Creating this liv- 
ing essence is the trick to mak- 
ing people like a character. Far 
too many female characters 
have been put into games sim- 
ply as tokens, usually as sexy 



bodies for use by marketing depart- 
ments. This is something to avoid. 

Male and female players react to the 
gender of a lead character in different 
ways. Players usually want to protect a 
good character of the opposite sex, so 
drawing on a person's primeval and 
innate response to the opposite sex is a 
powerful tool. If the character is attrac- 
tive, believable, and commands 
respect, players will grow fond of it. On 
the other hand, someone playing a 
good character of the same sex usually 
grows to admire the character and its 
characteristics. If the character has 
been designed well, the character can 
even develop into a role model for 
some players. Whatever the gender of 
the character, the fundamental rule for 
getting people to respond positively to 
the character is that the character must 
be likeable and admirable. 



The Halo Effect 

Some great psychology experiments 
have been conducted about the 
"halo effect," the results of which can 
apply to character design. Briefly, the 
halo effect postulates that we treat 
attractive people better than we do 
ugly people. Not only that, but we 
often make all sorts of subconscious 
assumptions based on looks. Good- 
looking people are often assumed by 
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Strangers to 
have other pos 
itive traits, such as being ''poised, inde- 
pendent, sociable, interesting, exciting, 
and sexually warm" according to 
Brigham. On the other hand, unattrac- 
tive people are apparently seen by 
strangers as more ''deviant," according 
to Jones and his colleagues (see the 
References section at the end of this 
article). 

I've heard arguments that game 
developers should not create a cast of 
highly attractive characters, either 
because it provides unrealistic role 
models for children or because some 
equate creating sexy characters with 
sexism. I don't consider it sexist to rep- 
resent males and females in an equally 
distorted way, but action comics have 
been criticized for years because they 
portray exaggerated strength and sexi- 
ness in characters. Note however, that 
as a medium, comics command 
one of the largest groups of 
enduring and instantly recogniz- 
able characters. 

Thus character designers 
should do everything in their 
power to make characters as 
attractive as possible. People's 
first impressions of characters 
will almost certainly come not 
from what they do, think, or 
say, but what they look like. If 
the character makes a good first 
visual impression, players will 
likely stay focused on it, allow- 
ing you to further entice them 
with the character's personality. 



Costume Design 



FIGURE 3 . The character shown left has been heavily 
overworked. The excessive detail and overuse of colors 
has left it muddy and confused. In contrast, the charac- 
ter on the right illustrates a cleaner design. 



Keeping a consistent cos- 
tume throughout a game is 
the best way to help imprint the 
character in a person's mind, so 
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costume changes should be avoided as 
much as possible until the character's 
visual design has become fully estab- 
lished. Once established though, giving 
a character some costume changes will 
increase its believability. 

Let's look at Indiana Jones again, as 
he appeared in films. Indiana wears his 
costume with some variations; some- 
times without the jacket, sometimes 
without the hat, and in certain brief 
scenes he wears a completely different 
outfit. All in all though, Indiana keeps 
a strong sense of consistency which 
contributes to a solid, consistent image 
in our imagination. 

The simpler a costume design is, the 
easier it is for a person to recognize 
and remember it (Figure 3). Complex, 
muddy, drab, and over-rendered 
clothing results in confusing, mud- 
dled characters. Try exaggerating 
essential elements of your character 
until you can strip it down to its 
essence, the simplest representation 
that gets across the meaning you are 
trying to represent. 

Color schemes should be kept 
bold and within a limited palette. 
That way the colors begin to sym- 
bolize a character, just as blue, 
gray, and a dash of yellow invokes 
Batman (Figure 4). 

It's always a good idea to try to 
put elements into a design that 
help symbolize the character's 
essence. Obvious examples of this 
technique include Hermes's 
winged feet or the web designs on 
Spiderman's costume. You can also 
leverage the subtler associations 
people make about clothing and 
accessories to provide more clues 
about the character: glasses for 
intelligence, cardigan sweaters for 
massive sexual magnetism, or 
whatever. 



FIGURE 4 . Batman 's color scheme is 
so strong that even with the added 
confusion of the film versions intro- 
ducing blacl<, you still can recognize 
him. 



whether the character is an Avatar or 
an Actor. 

I can't overstate the importance of 
body language when creating images of 
any character. Not only do people 
make dozens of snap assumptions 
based on a person's physical appear- 
ance and apparel, they also make 
strong judgments based on the way 
people carry themselves and their 
physical presence. 

Just the way people stand reveals 
enough information for others to read 
all sorts of traits about them. The trick 
is to be aware of this, know what mes- 
sages you want to give, and provide 
those cues clearly (Figure 5). 



Personality bounts 



FIGURE 5 . Even with all other visual clues 
stripped away, a person's pose can send very 
clear messages about a character. 



Far too many characters are portrayed 
in static poses designed to look "hard." 
Unfortunately, the quintessential hard 
look is the emotionless, squinty-eyed, 
Charles Bronson-style stance. This does 
not allow people to ''read" a character at 
all, but it works with Bronson and Clint 
Eastwood because that's the point of the 
''Man with No Name" tough guy — he's 
supposed to be unreadable. So many 
characters imitate this look that they all 
fade into an obscure morass of similari- 
ty. Instead, create some attitude 
through poses that provide clues about 
the character's personality. 

Poses are especially important for the 
static artwork typically used on game 
boxes and by marketing people. Dy- 
namic poses are far more interesting, 
striking, and memorable than static 
ones. If a character is meant to be an 
action character, then for goodness's 
sake show them in motion. 

Consider taking the final step and 
exaggerating a character's pose to the 
point that it actually begins to signify 
the character. If you create a set of 
strong, distinctive poses for your 
character, people will recognize 
these poses even when seen in sil- 
houette or from a great distance. 
Spiderman is an excellent example 
of a character that has a great array 
of extremely strong, immediately 
identifiable poses (Figure 6). 



Once you have a good, 
strikingly designed 
character, the next step is to 
work on conveying its 
personality. Again, the 
extent to which you 
need to portray 
personality 
depends 
on 
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Notion, The Fourth Dimension 

Just as with visual design and 
poses, it's incredibly important 
to consider how a character moves, 
and design around that aspect. The 
most important step is making a 
character move in a convincing 
way. That means showing weight, 
balance, and inertia. Unless you 
pay particular attention to the 
solidness that a character demon- 
strates while interacting with its 
environment, people will never 
accept it as anything but a group of 
weightless polygons. Every time a 
foot slides or a character snaps 
between animations, the illu- 
sion of life is totally shat- 
tered. Since computer 
game characters con- 
stantly repeat their 
animations, it is 
worth the extra 
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time 
to 

make 
movement 

animation as flawless as possible. 

Apply the concept of unique poses to 
the actual motion of a character. The 
way people walk suggests vast amounts 
of information about them, such as how 
they feel about themselves and their 
surroundings. If a character's move- 
ments are a consistent, exaggerated rep- 
resentation of its inner self, you can 
build up its personality while it moves 
about its environment. (As a side note, 
there is a vast difference between real- 
ism and believability — I feel you can 
always get a stronger, more universal 
emotional response from high-quality 
hand animation than you ever can from 
motion capture.) 

Awareness 

The key that Disney animators ulti- 
mately found to 
creating the illusion of 
life was showing their 
characters thinking. 
Making a character 
aware of its environ- 
ment has an incredible 
impact on its believabil- 
ity. If your character 
examines its surround- 
ings and the other char- 
acters in it, it automati- 
cally appears to be 
thinking about what it's 
looking at. Awareness 
doesn't just end with 
where a character looks, 
it extends to its reac- 
tions to its environ- 
ment. A character 
can give emotional 



responses 
to what it sees, 
such as surprise, fear, 
happiness, and so on. 
One aspect of awareness 
that reinforces a character's 
believability is how aware other char- 
acters are of your main character. 
Besides just awareness of presence, 
emotional responses by NPCs toward 
the main character add immeasurably 
to its substance and believability. Note, 
however, that the player will be affect- 
ed by how NPCs react to the main 
character. Unless you want to lower a 
player's opinion of the main character, 
NPCs should generally react positively 
towards it. 



What's Your Story? 



■ like to work out some sort of back- 
ground history for a character, even 
if it only helps to flesh things out in 
my own head. Don't go too far when 
creating the history, though — it's 
risky to give a main character loads of 
hidden motivations that might con- 
flict with the player's, and the charac- 
ter could react in ways that make the 
player feel uncomfortable. At the end 
of the day, a game character shouldn't 



FIGURE 6 . Spiderman 's poses are so strong that you 
can recognize him from them alone. 



have anything more than 
superficial personality traits 
since, whatever the POV, the 
player needs to retain as 
much control as possible. A bit of 
background just helps solidify the 
character design process so that it can 
be consistent. 

If a character is going to speak, the 
benefits of having a decent voice artist 
are immeasurable. We glean a host of 
information from each other's voices 
that has nothing to do with the nature 
or content of the words spoken. We lis- 
ten to the timbre, the accent, and the 
range of a voice to make basic assump- 
tions. More importantly though, we lis- 
ten to the rich subtle inflections that 
hint at whether a person is sarcastic, 
sincere, intelligent, or has a sense of 
humor. Only highly skilled actors can 
evoke all of this hidden information as 
they deliver their lines. If anything is 
lacking in the voice acting, then you 
can't inject personality into a character 
even if all its other design elements are 
spot-on. 

So much about character design is 
subjective. I mean, what is attractive? 
On that point alone you could argue 
for hours. But one very important 
thing remains to be stated. Any of the 
points I've discussed can, and probably 
should be turned on their heads if you 
want to create new and exciting char- 
acters. Guidelines such as these are just 
guidelines: ingenuity, humor, and orig- 
inality require that rules be broken. ■ 
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Testing When You're 
Worlds Apart 



b u Marfe Tit 



o m a A 




testers report to different companies 
and are separated geographically, com- 
plications naturally arise. But regard- 
less of your business structure, the test- 
ing and development teams should 
share the same goal: to release the 
highest quality game possible. Here are 
some guidelines to help an outside test- 
ing team achieve that goal. 



here are a number of situations in which a test- 



ing team can find itself working with an exter- 
nal developer. Probably the two most common 



scenarios are the publisher-developer relationship 



(which itself can operate under a number of models) 
and when the testers work for an outsourced testing 



company. Testing games can be difficult under the 



best of circumstances, but when developers and 



Kick It Off Right 



It's important to kick off the product 
testing process well. Here at Micro- 
soft we try to spend some social time 
with the development team and work 
through our anticipated project issues. 
Whether you're a developer or a tester, 
you should see how the ''other side" 
operates and meet everyone you'll be 
working with as early in the process as 
possible. The hard discussions will 
begin sooner than anyone would like. 



but they become easier when some per- 
sonal contact has already been made. 
People also tend to be less flexible in 
e-mail than they are in person. 

Early in the game's development, the 
testers and developers should sit down 
and develop a shared glossary of terms 
that are relevant to the project so 
there's no miscommunication later. 
Terms such as "milestone," "alpha ver- 
sion," and "code complete" mean dif- 
ferent things to different teams, so 
establishing and documenting terms 
from the outset will head off misper- 
ceptions. What terminology you chose 
isn't important; what is critical is that 
all parties understand that terminolo- 
gy. Take time to define what "quality" 
means to the testers and developers. 



and make sure that everyone buys into 
that definition. Do the same with the 
definition of "bug." 

Decide the methods by which you 
will measure the status of the project, 
and how these measurements will be 
conducted. There are many ways to 
measure a product, and you will proba- 
bly use a wide variety of metrics to 
judge progress. You can hinge mile- 
stone acceptances on bug count, fea- 
ture implementation, play-testing 
results, multiplayer success rates, per- 
formance, or all of the above. Clarify- 
ing this from the beginning should 
minimize arguments later, when ques- 
tions such as "What is 'good enough'?" 
and "When do we know when the 
game is 'done'?" arise. This agreement 
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A configuration lab is one of the best resources a publish- 
er can provide. 



should be sought at the beginning of 
the product, and continually rein- 
forced as the project proceeds. It is best 
to document these agreements in writ- 
ing once a consensus is reached. This 
gives the development team a goal to 
shoot for, and there is no confusion as 
to where the bar is. At Microsoft, mile- 
stone criteria not only list the features 
to be completed, but also specific bug- 
tracking goals and multiplayer success 
rates. For example, a milestone might 
have the criterion ''no active severity 1 
bugs, and at least 60 percent success on 
four-player ISP games." 

Testers should continue to provide 
these measurement criteria to the 
development team as early and often as 
possible. I try to prepare the metrics 
and expectations for the next set of 
deliverables as soon as the last set has 
been signed off on. If your milestones 
are more than four to six weeks apart, 
try to set measurable goals and targets 
no more than six weeks from your last 
checkpoint. 

I recommend sharing your upcom- 
ing build verification tests and mile- 
stone acceptance tests with the devel- 
opers. As soon as you have written 
them, send them to the development 
team. Encourage the development 
team to run these tests before each 
build is delivered. By doing so, the 
developers will know exactly what is 
expected of their game and they'll have 
the means to assess its progress prior to 
submitting the build to the testers. This 
also helps manage the expectations of 
the development team, and prevents 
them from saying, ''We didn't know 
the game was supposed to do this!" 

Setting up and documenting how 
testing will be handled is critical. There 
are myriad details associated with test- 
ing a game, and you should make every 
effort to lock down the steps of your 
testing schedule as early as possible. Set 
up processes you can live with. In gen- 
eral, you will need to integrate your 
testing with the development schedule. 
There are times, however, when it is 
very important to make sure that the 
development schedule takes the testing 
needs into account. When schedules 
are being developed, I try to analyze 
them from two perspectives. First, I try 
to figure out what feature is going to be 
the most difficult to develop. Will it be 
the AI, the multiplayer code, or some- 
thing else that must be finished before 



content is created? 
Features like these are 
always risky, and 
when possible, front- 
loading them in the 
schedule helps make 
sure that they get 
completed and stabi- 
lized. Second, I look 
for features that will 
have a lot of impact 
on game play or take 
a long time to test. 
While these features 
may not be technical- 
ly difficult to imple- 
ment, they tend to 
require a lot of tweak- 
ing and tuning. If 
you get the core func- 
tionality of these fea- 
tures done and tested 
early, you should have plenty of time 
to adjust them and perfect the game 
play as the product evolves. Every title 
has its own list of risky features, and 
the sooner you can isolate and control 
them, the better. 



Builds 

Builds are important steps in the 
testing process; they are the criti- 
cal and ultimate deliverable to the test- 
ing team. The testing and development 
teams should agree when and how 
often builds will be delivered. Typically 
at Microsoft we make this decision col- 
lectively with the producer, lead devel- 
oper, and test lead. 

Set up a schedule for delivering 
builds that makes sense and try to stick 
to a pattern. Maybe it is the first of the 
month, or every other Friday. I find it 
helps to have a set day on which the 
build will be sent. If the entire develop- 
ment team knows that every Thursday 
at noon is the last time to check in 
code before the build is made, it starts 
to become a habit. Typically at Micro- 
soft the schedule for builds changes as 
the project progresses, and builds are 
delivered more frequently as the ship- 
ping date approaches. As a test lead, I 
begin to get a bit nervous whenever I 
go longer than one month without a 
new build being delivered for testing, 
but I expect the development team to 
be building the product internally at 
least once a week. 



The testing team should make it 
clear to the developers what the expec- 
tations are for each build, and a written 
list is a great tool to have at the project 
kickoff meeting. Does the testing team 
want to receive the build via FTP or 
CD-ROM? Should a release executable 
or debug build be sent? Should a .PDB 
(program database) file be sent? Are 
there any support tools that need to be 
delivered at the same time, such as an 
editor or a file compression tool? 
Whatever you do, structure the builds 
such that the development team 
doesn't fear the prospect of sending a 
build to the test team. 

Avoid requesting surprise builds 
from a development team. Assuming 
you've chosen a reasonable interval at 
which a build should be delivered 
(say, every other Friday), make sure 
that everyone understands what is 
expected. I recommend assigning 
responsibility to one person on the 
development team and one on the 
testing team for the build. The former 
is responsible for building the product 
and sending it off to the test team, 
and the latter receives or downloads 
the build and prepares it for release to 
the team. At Microsoft we typically do 
the setup for the product, so we ask 
developers to send us the raw files, 
and then the test lead integrates the 
build with the set up and distributes it 
to the rest of the test team. 

There should be an understanding 
between the testing and development 
teams as to the importance of always 
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FIGURE 1 . l/l/e froc/c everything in RAID. The database bacl<-end gives us the abil- 
ity to search and query on almost any element of a bug. 



keeping a buildable code base on 
hand. It is very important to build the 
project frequently, as a build is the 
best indicator of the status of the prod- 
uct. A process that results in frequent 
builds gets your product to a known 
level and gives you a great way to see 
progress. By keeping to a frequent 
build schedule, any big snag or step 
backwards is visible to the entire team 
very quickly. 

Making a build for the testing team 
should not be an event; it should not 
take days. At Microsoft we encourage 
developers to invest in a build process. 
We try to help developers get a system 
set up that lets them build their prod- 
uct every day, just by pressing a but- 
ton. If you cannot build the product, or 
something breaks this process, this is a 
big warning flag. With a frequent build 
schedule, such problems are exposed 
immediately. 

Bug Tracking 

Standardize a uniform way to report 
and track bugs using some sort of 
database system, one that lets you 
query the bug database for specific 
issues and get a quick snapshot of the 
product's status. A database is a lot eas- 



ier for a team to work with than a 
spreadsheet. At Microsoft we have an 
internal tool called RAID (''kills bugs 
dead!"). It runs on a SQL back end and 
is accessible from every desktop at 
Microsoft. With some effort, RAID can 
also be set up and shared with our 
external partners. We put everything 
into RAID (Figure 1). 

When a bug is entered into the data- 
base, it is assigned a priority and severi- 
ty, tied to a specific area of the product, 
and then assigned to the appropriate 
person for fixing or research. When the 
fix is made, the bug status is changed 
from active to resolved, and then 
assigned back to whoever opened the 
bug. The tester then regresses the bug 
and verifies the fix before closing the 
bug. Only testers close bugs, which 
ensures that a fix is well tested before 
the issue is closed. 

Bug reports should be as detailed as 
possible. When you are not at the same 
location as the developers, this is even 
more important. Reports should contain 
all the information that will be needed 
to reproduce the bug on a developer's 
machine. A typical bug report also con- 
tains a title, which is the one-line 
description of the bug. A good title 
makes clear in just one sentence exactly 
what the bug is. Next, in the details 



about the bug itself, there should be a 
more verbose description of the prob- 
lem, and the shortest possible list of 
steps to reproduce the bug. The last 
component of a good bug description 
should be the expected behavior, had 
there been no bug. Often this seems 
obvious, but often the expected behav- 
ior of the product in this situation isn't 
clear or is different from the specifica- 
tion. If the tester takes the time to clari- 
fy what is expected of the product, the 
developer can quickly determine if there 
is confusion. Also, if a change to the 
product is needed, the developer knows 
what the tester expects the product to 
do before changes are made. We also 
make sure to include any debug infor- 
mation (call stacks, log information, 
and so on) and details about the hard- 
ware and operating system of the 
machine where the bug was found. If 
you can save the developer a phone call 
or an e-mail to ask a question, it's worth 
the extra time. 

Make sure that the development 
team has equal access to whatever you 
use to track bugs. Ideally, every devel- 
oper should have real-time access to 
their bugs at their desk. Whenever I set 
up a database for a new product, I open 
the first bug and fill it with a bunch of 
information about the process the 
team has agreed upon for bug tracking: 
things such as the life cycle of a bug, a 
template for a new bug, an explanation 
of the version numbering system, and 
anything else that's appropriate to the 
product. If anyone forgets the process 
or new people join the team, they can 
always open up bug number one and 
access this information. 

Access to the bug database should be 
available to as many members of the 
team as possible. Testers, developers, 
artists, writers, designers, producers — 
everyone — should be able to get in to 
view bugs. Your bug list shouldn't be 
hidden from members of the develop- 
ment or testing team; it is the most 
accurate description of the state of the 
product. Also, avoid any bug-tracking 
solutions based on two different tools 
— the development and testing teams 
should use the same tool to capture 
this information so that tracking the 
status of bugs and sharing information 
back and forth between the two teams 
is easy and seamless. One shared data- 
base that everyone can access promotes 
communication and ensures that 
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everyone has the same information 
and priorities. 



Team Communication 

Every company has different styles 
and methods of communication. 
For instance, some development teams 
prefer to funnel testing information 
through their producer, while others 
want their developers to interface 
directly with individual testers. As 
such, it^s important determine how the 
testing and development teams will 
interact. 

I've found that many producers want 
to restrict the contact between the test- 
ing and development teams to pro- 
mote consistency in bug tracking and 
prevent developers from talking with 
random testers every time they call. 
Whatever communication system is 
put in place, it's important that the test 
team has a way to get questions and 
concerns addressed. However, once the 
''code complete" stage has been 
reached, it's important for testers to 
communicate directly with individual 
developers. Direct communication at 
this stage increases the productivity of 
both teams. 



Triage 



Bug triage meetings are much easi- 
er when the development and 
testing teams meet in person. Early in 
the development of the game, all those 
involved should agree upon the 
method of triage and who will conduct 
it. At Microsoft, the program manager, 
the test lead, the user education lead, 
and the support lead attend bug triage 
meetings from the Microsoft side. On 
the developer's end, usually the pro- 
ducer, designer, and development lead 
attend triage meetings, although this 
varies from team to team. Whatever 
the staff structure, make sure that the 
primary stakeholders in the product are 
represented. 

As you triage bugs, make sure every- 
one understands each bug completely 
before deciding to fix it or blow it off. 
Because these are often difficult deci- 
sions with substantial consequences, 
and because bug reports can sometimes 
fail to clarify the scope of a bug, try to 
review bugs in the order of the tester 
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FIGURE 2 . It is valuable to track how bugs are addressed. Your fix and find rates 
can help you figure out when your product is close to shipping. 



that reported them and then invite 
that tester to the meeting when the 
bugs are discussed. This takes a little 
more time than just reading through 
the list with the committee members, 
but allowing testers to present their 
bugs often reveals reasons to fix the 
bug that no one had thought about. It 
also makes the test team feel that their 
issues are taken seriously, even if some 
bugs aren't fixed. 

Honesty, above all, is critical to a 
good bug triage meeting. As a develop- 
er, be honest about the scope of the fix 
and any involved risks. As a tester, be 
honest about how severe the bug is, 
and your comfort level accepting a fix. 
Ideally, the decision to fix or ignore a 
bug should be a unanimous one. 

Face Time Is Critical 

There are some things that you can 
do throughout the process that 
will increase the likelihood of your test 
team delivering a high-quality game. 
Above all, share information you have 
about the product with other team 
members, both up and down the 
chain. Status reports on the team and 
the product are never a bad idea. Most 
product leads at Microsoft write status 
reports at least weekly, which often 
include rolled-up status reports from 
their team. These reports are typically 
available on an internal web site or 
sent out in e-mail, and are available to 
the group management and the entire 
team. Part of a tester's job is to commu- 
nicate the status of the product — at 



Microsoft that is even in the tester's job 
description. In my experience, more 
software development problems stem 
from poor communication than either 
technical or financial issues. 

Face time between testers and devel- 
opers is vital. Don't be afraid to put 
people on an airplane and hold meet- 
ings between the testing and develop- 
ment teams. Where you hold such 
meetings should depend on the meet- 
ing topic. For instance, as a publisher, 
there are things that we do at Microsoft 
that our developers aren't as equipped 
for, so we often have the development 
teams fly to our office and spend a few 
days or weeks on-site to solve specific 
problems. Take advantage of testing 
space and park whoever is fixing your 
configuration bugs in the configuration 
lab — do whatever is appropriate for 
your project. 

One project at Microsoft was within 
a few weeks of shipping when suddenly 
there was major problem with the mul- 
tiplayer technology. It was so bad we 
couldn't even complete LAN games, let 
alone games played via the Internet. 
Since it was so close to our target ship 
date, we scrambled to round up as 
many testers as possible to analyze the 
problem, and had three development 
team members join us for almost two 
weeks. The problem unfolded before us 
like the layers of an onion; we fixed 
one bug only to find another right 
underneath. Having the developers 
work alongside testers helped fix the 
problem rapidly. We eventually 
shipped the game on time with a solid 
multiplayer component. 
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Understand Your Role As a Tester 

Testing is a key part of the process 
of delivering a game. However, 
outside development teams may not 
realize the exact value you can add to 
their game. There is a great deal of vari- 
ation in the quality of testing resources 
in our industry, so development teams 
are often leery of letting a new testing 
team exercise too much influence over 
their product. 

To combat that situation, make your 
motivations as a testing team clear to 
the developers. Often this can be as 
simple as stating to the developers, 
"My job is to help you make this the 
highest quality product possible." One 
of the best ways I found to make devel- 
opers comfortable with our test team is 
to establish ourselves as a service for 
them. This doesn't imply that we 
testers are a lower class of people. We 
just let the developers know that we 
think of them as our client, and that 
our relationship with them is based 
upon this belief. We want to know 
what we can do to make their jobs easi- 
er. We ask developers if we can unit 
test their code before it gets checked in, 
if we can run specific tests right away 
upon build delivery, and so on. Take 
the time to figure out what will make 
the process easier for the development 
team and see if you can provide it. 

Often developers don't know how to 
make the best use of testing resources. 
Sometimes they don't really under- 
stand what testers do exactly. If you 
make yourself as available as possible 
to them, you will find that most devel- 
opers become quite excited about the 
prospect of having testers work with 
them directly. I've seen situations 
where a developer and tester worked 
so well together prioritizing which 
bugs to fix in their areas that together 
they convinced the team when not to 
touch something. A cooperative devel- 
oper-tester relationship like that can 
make much greater strides toward 
releasing a bug-free product than if the 
developers and testers work against 
each other. 

During the course of a game project 
I've seen producers and developers ask 
testers to accept or change something 
about the game. (The common request 
is, ''Can we let this slide a little?") 
When you're asked to alter the test 
plan in some way, determine the costs 



Play testers hard at work. 



and risks to your 
team and the 
product if you 
accommodate the 
request. In some 
cases, a little bit of 
flexibility can go a 
long way, and ulti- 
mately you have 
to do what's right 
for the product, 
not cling blindly 
to "the way things 
should be done." 
On the other 
hand, never put 
yourself or the test 
team in an 
uncomfortable 
position. 

As a rule, show- 
stoppers should be 

where you plant your flag and demand 
a bug fix. The definition of a show- 
stopper is different for every company 
and every product. (Chances are that 
you will know one when you see one. 
A show-stopper is often a bug you find 
two days before you are supposed to 
ship that gives you that sick-to-the- 
stomach feeling.) The realities of soft- 
ware development prevent most devel- 
opers from shipping 100 percent 
bug-free products, but you should look 
at every bug and consider its effect on 
the consumer. How many people will 
see it? How severe are its effects? Is it a 
crisis, or merely an irritant? Is there 
some sort of data loss associated with 
the bug? Is there a workaround for the 
player? How long will it take the play- 
er who hits this bug to get back into 
enjoying the game? What's the likeli- 
hood that it will generate a call to your 
technical support department? Can 
the player proceed past the bug at all? 
The answers to these questions must 
be compared with the risks and costs 
of fixing the bug. Look at it from 
the perspective of the consumer's 
expectations. 

At Microsoft we don't have many 
hard-and-fast rules on how bug-free a 
product must be before we ship, but we 
try to maintain a high bar for the prod- 
uct. All bugs must be closed before a 
product ships. Being "closed" isn't 
always the same as "fixed," but it 
means that a tester agreed that it would 
be O.K. to ship the product with that 
bug. In general, we fix all known bugs 




that cause system crashes. We also 
compare the game against previous 
titles. For example, we compare our 
frame rate at our minimum configura- 
tion against other games running on 
the same hardware. 



When the Budgeting Axe Falls 

Testing is often shortchanged — 
sometimes never even considered 
— when the product development bud- 
get is drawn up. Other times, a "stan- 
dard" cost will be inserted into the 
development budget's testing line 
item, without considering the game's 
scope. Ideally, the test lead should be 
involved in preparing the product bud- 
get, but that's rare. The sad truth is that 
testing funds are often the first to get 
scaled back when budgetary goals must 
be met. 

When faced with a situation where 
staffing and financial constraints pre- 
vent you from properly testing a prod- 
uct, make it your responsibility to 
explain to management that these cuts 
or shortfalls will lead to insufficient 
testing and affect product quality. My 
test manager responds to the threat of 
budget cuts simply by asking senior 
management, "What part of the prod- 
uct would you like us not to test?" Usu- 
ally the response is a bewildered look. 
Here are some other techniques for 
defending the testing budget: 

• Remind those in charge that up- 
front testing helps avoid post-ship 
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expenses; technical support costs 
are often figured on a per-call basis, 
and depending on your company's 
structure, those calls can be a very 
expensive reminder of the benefits 
of testing. 

• If management offers to patch 
instead of test, explain that patch- 
ing a product can be a grim propo- 
sition that actually involves double 
costs: the time the team takes to fix 
bugs and prepare the patch for 
release, plus the opportunity cost 
of delaying the next product. 

• Play the reputation card. Remind 
senior management that con- 
sumers remember low-quality 
games, and that brand reputation is 
as real a corporate asset as cash. 

• Finally, bring up the fact that there 
have been a number of very expen- 
sive product recalls in the past cou- 
ple of years due to problems like 
setup bugs that caused users to lose 
data, and the discovery of unau- 
thorized content on CDs. That 
should be the nightmare scenario 
of anyone involved with managing 
product costs. 

Ignorance of the benefits of testing 
isn't confined to upper management. 
There are developers out there who 
believe that they don't need any help 
from a test team; they are confident 
that they will find all bugs themselves 
and deliver a perfect drop to the pub- 
lisher on the day of release. I suppose it 
is possible that some developers are 
capable of such perfection, but I've 
never met any. I've only met develop- 
ers who think they are this good. Work- 
ing with this type of developer tends to 
be painful and confrontational because 
such an individual won't value your 
contribution and probably won't be 
flexible about meeting the needs of the 
test team. 

Unfortunately, no single solution 
shakes such developers from this mode 
of thought. Sometimes they react well 
when testers find bugs in their code, 
other times they don't. One strategy 
that has worked well for me is posi- 
tioning testers as programmers' 
"aides." Explain to the developer that 
you can take some of the cleanup work 
off his hands. Offer to find invalid and 
unexpected cases in the program after 
they have unit tested their code. 
Market yourself as a service to the 
developer. 



Make Each Project a Lesson 

Every time you go through the test- 
ing process with a different devel- 
oper you learn a new way to conduct 
tests. Don't forget these lessons. If 
something goes poorly, remember the 
episode and employ that knowledge in 
future projects. Examine the factors 
that led up to it so you'll be aware of 
them next time. And of course, if 
something works well, think about 
how you can apply those same tactics 
to a new situation. 

Many companies, including Micro- 
soft, hold thorough postmortem meet- 
ings after a game has shipped, in which 
everyone from the development and 
testing teams gathers together to talk 
about what went well and badly. Whe- 
ther or not your company holds such 
meetings, prepare as if you'll attend 
such a meeting some day. On the day 
you start a new project, create a person- 
al postmortem document, and make 
entries when things go well and badly. 
Having a written record helps you ad- 
dress problems for the next project, and 
constantly updating that document pre- 
vents incidents from disappearing from 
your memory once the product ships. 



Above all, as a tester you must be 
loyal to the product's quality. It's your 
job to ship the best game possible. 
Whenever you find yourself unsure 
about what course of action to take, ask 
yourself, ''What will make this a better 
product?" Once you ask yourself that, 
choices usually become easy. ■ 
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Epic Games' 

Unreal Tournament 



btf Brandan ReinUarf 



NREAL Tournament, released in November 1999, 



was, in a way, an accident. After the original 
Unreal was completed. Epic wanted to follow up 



the project with some sort of add-on pack. Unreal 



multiplayer code was very poor, so the team felt 



that an expansion that improved multiplayer would be 



ideal. As feature lists grew and patches to Unreal were released, the add- 



on turned into a complete and independent game. 





Unreal Tournament has certainly seen a very 



nontraditional development cycle, one that I feel 
would not have succeeded in any other genre. 



Ultimately, our decisions paid off, because the 



game earned more than five "Game of the Year" 
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A close-up shot of the Black Thunder skin on Shane 
Caudle's Malei model. This was one of the first new skins 
developed for Unreal Tournament. 



awards and is consistently rated in the top ninetieth per- 
centile in reviews. The online community is producing 
excellent expansions and modifications to the game and we 
feel that Unreal Tournament will be around for a long time 
to come. 



Early Development 

A proper look at the development of Unreal Tournament 
begins with the completion of Unreal. The Unreal 
engine was four years under development and the team was 
wearing down. When the game shipped, it met with a large 
amount of acclaim, but that positive image was tarnished 
over time as hardcore players began to complain about the 
terrible network support. The Unreal team was now faced 
with several more months of work on the game, essentially 
to bring it to the point it should have been at when it was 
put on shelves. 

Early in the process, plans were discussed to work on an 
official Epic add-on to Unreal. The add-on would introduce 
much-improved network play, new maps, and probably 
some new game features. The original ideas for the add-on 
were never put on paper and it never had a name. I was 
hired by Epic in August 1998 to assist with patching Unreal. 
Eventually I started to write new code for the add-on with 
Steve Polge. 

Initial work on the add-on in early summer 1998 was 
made difficult by the fact that Epic was a virtual company. 
The last year of Unreal's development took place in Canada, 
with the U.S. -based Epic team flying back and forth to work 
with Digital Extremes in London, Ontario. When Unreal 
was finished, no one at Epic wanted to travel anywhere, but 
at the same time the team recognized that they needed to 
move to a central location. The team decided to relocate all 
of its employees to Raleigh, N.C. 

By September 1998 everyone was together or had a travel 
plan. Work started to come together rapidly on the add-on 
project. Steve Polge had laid the groundwork for several new 
game types, including Capture the Flag and Domination. 
The level designers had five or six good maps ready for test- 



ing. Throughout sporadic but intense meetings, the team 
agreed to focus the add-on entirely on improving the multi- 
player aspect of the game with new features and better net 
code. 

The amount of content grew and we soon realized we had 
a much larger project on our hands than we had originally 
thought. In November, after meetings with our publisher GT 
Interactive, Mark Rein suggested we turn the add-on into a 
separate game. Initially, the team opposed the idea. We 
wanted to finish the project quickly and move on to some- 
thing fresh. The promise of a much higher profit potential, 
coupled with our recognition of the state of the project 
finally led us to agree with GT. In December, the name 
Unreal: Tournament Edition was chosen, with ''Edition" 
subsequently dropped from the title. 



A Game Takes Shape 



Epic's internal structure is extremely liberal, probably the 
most liberal in the entire gaming industry. Programmers 
work on the projects they want to work on, with major fea- 
tures being assigned to whoever steps forward to take on the 
task. Artists work with level designers but are given signifi- 
cant design freedom. Level designers work on the kinds of 
maps they think would be cool. This design philosophy per- 
vaded Unreal Tournament's development. 

In December, I downloaded a sample of a new Unreal 
mod under development by an Australian named Jack 
Porter. The mod, UBrowser, was a server browser using a 
Windows-like GUI. It was impressive, so I showed it to James 
Schmalz, lead designer at Digital Extremes, who said, ''We 
need that, we need to hire this guy." A few weeks later Jack 
was a part of the team, expanding his UWindow GUI and 
reworking Unreal Tournament's menus to use the system. 
Jack fit into the team perfectly, bringing a complete solution 
for the interface and menus as well as his own independent 
programming initiative. 

Weekly meetings infused order into our chaotic corporate 
structure. Everyone would debate and yell about what fea- 
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tures were cool and what fea- 
tures sucked. The assignment of 
major features was largely auto- 
matic. Tim Sweeney worked on 
improving net code and engine 
fixes. Steve Polge wrote the origi- 
nal AI code and focused on 
adding player orders and other 
improvements (in addition to 
filling out the new game types). 
Jack had the windowing system 
and a lot of menus to work on. 
Programmer Erik de Neve was in 
Europe putting together level-of- 
detail code as well as experi- 
menting with next-generation 
technology. I worked on the sin- 
gle-player game, game-play fea- 
tures, scoreboards, HUDs, special 
level actors, tutorials, and wrote 
a lot of the game's story and 
character background content. 

The best features were added 
entirely by the initiative of indi- 
viduals. Level designer Cedric 
'Tnoxx" Fiorentino designed 
CTF-Face, an extremely popular 
Capture the Flag map. I added 
the Multi-Kill system after a 
short discussion with lead 
designer Cliff Bleszinski sparked 
the idea, and Jack implemented 
decals shortly before we shipped. 
It was this individual creativity 
that ultimately bound the team 
together. Each new feature 
infused everyone with the 
enthusiasm to add more. 

Once the first batch of new 
player models, weapon models, and 
maps was completed we realized we 
had a game quite different from 
Unreal. Feedback from the Unreal 
deathmatch community (including the 
highly vocal Quake community's com- 
plaints) also drove our designs. Subtle 
alterations to player movement and 
control changed the feel of the game 
completely. Some changes in game 
play — such as whether to enable 
weapon-stay in single player — were 
controversial, so we held polls on pop- 
ular Unreal message boards. 

Throughout the spring and summer 
of 1999, Epic was pursuing contract 
renegotiations with GT Interactive. 
Everyone believed the game could ship 
at any time, so development became 
stop-and-go. We would be in a code 
lockdown one week and adding major 
new features the next. The result of 




Unreal Tournament's deathmatch maps were not con- 
strained to any one particular theme or timeframe. 
Cliff Bleszinsi<i*s DM-Barricade, shown above, is a cas 
tie floating above a storm, while Pancho Eel<els* DM- 
Galleon is a massive ship sailing the ocean (shown 
top). 



this jarring development cycle was 
good and bad. The periods of code 
lockdown allowed us more time to 
play-test and fix bugs, which con- 
tributed greatly to the game's overall 
polish. On the other hand, it prevented 
us from adding many features that 
would have otherwise been included 
and it was detrimental to the morale of 
the team. We liked working on Unreal 
Tournament, but it still felt like old 
technology to us. The world had seen 
the Unreal engine; we were ready to 
move on. 



New Code, New Features 

As it turned out, though, we had a 
lot of time to enhance the engine. 
Unreal was before its time and a lot of 
the content and code was rushed by 



the need to ship. With Unreal 
Tournament, the team had a lot 
of time to use previously unex- 
plored engine features. Erik de 
Neve's level-of-detail code 
ended up really speeding the 
game up, giving us room for 
beefier characters and more 
map decorations. 

Early on we experimented 
with using 16 256x256 textures 
per player, but opted for three 
or four 256x256 pieces out of 
memory considerations. This 
quadrupled the detail available 
to our skin artists for the player 
models. Reserving one of the 
256x256 textures for the head 
alone allowed us to mix and 
match body skins with heads, 
yielding a massive amount of 
customization with only a small 
amount of work. Another one 
of the 256x256 textures was 
reserved for team color bits, so 
that a player skin could encom- 
pass all five possible team colors 
(none, red, blue, yellow, green) 
without too much memory use. 

Level design didn't stand still 
either. Changing from single- 
player to deathmatch-oriented 
design was refreshing for the 
designers, but not without its 
unique challenges. One issue 
was the task of balancing the 
number of "hardcore" maps 
with ''theme" maps. A hardcore 
map focuses entirely on layout 
and game play, while the overall style 
of the map comes second. Theme 
maps, on the other hand, focus on a 
unifying idea or look and build from 
that. For example, the Koos Galleon, 
designed by Pancho Eekels of Digital 
Extremes, is a large sailing ship. It's a 
very beautiful level, but focuses on the 
theme of being a ship more than being 
a deathmatch map. 

The Unreal Tournament team decid- 
ed that mixing the two styles was the 
best approach. While most magazine 
reviews have expressed frustration at 
the theme-oriented maps, we didn't 
want to appeal to only the hardcore 
crowd. Including maps that were 
designed for their look and feel increas- 
es the game's interest to average play- 
ers who aren't skilled enough at the 
game to benefit from hardcore designs. 
Realism through textures and architec- 
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ture is one of the Unreal 
engine's strengths and it 
was critical that we 
exploit that strength. 
Ultimately, we shipped 
Unreal Tournament 
with somewhere around 
45 to 50 maps, offering 
more than enough vari- 
ety and replay value for 
everyone. 

Another task we faced 
was choosing which of 
Unreal's weapons to keep 
and which to ditch. Un- 
real Tournament has 
two firing modes which 
makes designing a 
weapon like designing 
two weapons in one. 
Unreal's stinger and dis- 
persion pistol were not 
needed in Unreal Tour- 
nament. Those weapons 
were good in Unreal, because a player 
needed to start with simple, weak 
weapons and build up. In Unreal 
Tournament, all the weapons had to be 
equally effective and carefully balanced. 
A player good with the minigun needed 
to be lethal with it. A player good with 
the pulse gun needed to be lethal with 
it. Eventually we settled on the current 
load-out, but made quite a few game- 
play changes to the weapons that stayed 
from Unreal. Each weapon was also 
given a much more beefed-up look and 
sound. 

An interesting little anecdote: GT 
started doing promotion for Unreal 
Tournament before the new rocket 
launcher was finished. They produced 
a lot of marketing material with old 
screenshots showing the eightball 
launcher from Unreal. If you look at 
the gold trophy used in the print ads, 
youTl see the characters at the top are 
holding eightballs, a weapon that isn't 
in Unreal Tournament. 



In the End, It All Uorked Out 

While the talents and devotion of 
individual team members creat- 
ed the content, the overall team spirit 
tied it together. Unreal Tournament's 
design process was often reckless, but 
the game that resulted is nevertheless 
very polished and a hell of a lot of fun. 
The deathmatch-focused first-person 



Unreal Tournament used from three to four 256x256 textures per 
model. This allowed us to focus lot of detail in the head and face 
area. Within the game a player can choose a sl<in and then swap 
through several different faces. This means players on a team can 
wear identical armor and clothing but have unique faces. 



shooter doesn't need a story, dialogue, 
or scripted sequences, which are all fea- 
tures that more or less require an orga- 
nized design. Had we applied our 
hodgepodge design approach to a more 
focused genre, we probably would not 
have had such a successful game. 
Unreal Tournament should not be 
seen as a lesson in how to design a 
game, but as a lesson on how to orga- 
nize a small team of developers. 



What Went Right 



1 Smart internal marketing team. At 
# the front of Epic's public rela- 
tions were Mark Rein and Jay Wilbur. 
Their job was particularly difficult dur- 
ing the development of Unreal Tour- 
nament. The media perceived us as 
impossible upstarts, taking an engine 
with terrible net-play and attempting 
to compete against id Software, the 
industry multiplayer champion. Both 
Mark and Jay fought hard to win over 
supporters in the online and magazine 
press. Mark made sure that the team 
stayed professional and that everyone 
was saying what he needed to be say- 
ing. Jay hunted down potential engine 
licensees, and helped establish a level 
of curiosity among the community and 
media. 

Unreal Tournament was able to 
garner significant magazine coverage 
because of the ongoing ''Quake killer" 



debates. Mark and Jay 
worked to turn the initially 
negative public response 
into something positive. 
While we felt that our game 
would definitely stand on 
its own, we had to ensure 
that the positives were 
being clearly broadcast. 
Epic was very careful to 
avoid mentioning Quake 3: 
Arena whenever possible, 
keeping the focus solely on 
Unreal Tournament's fea- 
tures and staying away 
from comparative previews. 
Most interviews and pre- 
views would ask us the 
inevitable "What about 
Quake 3?" question, to 
which we tried to answer 
with complete respect for 
id's project. Everyone knew 
that Unreal Tournament 
and Quake 3 would be pitted against 
each other. Mark and Jay established 
very early on that the competition 
would be friendly. 

2 Liberal internal structure, open 
# DESIGN DISCUSSION. The laid-back 
environment that both Epic and 
Digital Extremes fostered greatly 
enhanced the quality of Unreal Tour- 
nament. Everyone was free to suggest 
or implement an idea. Programmers 
had as much design freedom as anyone 
else on the team. Cliff Bleszinski (Epic) 
and James Schmalz (DE) were the lead 
designers of their respective companies 
and served as content filters. They 
worked towards focusing the ideas put 
forth in the meetings. In addition, 
both of them contributed significantly 
to the final game content. James 
designed two of the player models and 
created many skins and faces, while 
Cliff designed many of the game's best 
maps. 

Team members were allowed to 
come into work when they wanted and 
stay however long they felt like being 
there. The only requirement was that 
every member attend a weekly design 
and focus meeting. This system worked 
because Epic was very careful to hire 
mature, dedicated employees and the 
core development team was kept small. 
The open hours often saw team mem- 
bers working a 24-hour day, sleeping 
on a couch for six hours, and then 
working another 24-hour day. 
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In addition to fostering a hardcore 
work ethic, the system created a side- 
ways information flow. A programmer 
would go straight to the artist he needed 
something from, instead of through an 
art director. The fast communication 
allowed the programmers to stomp out 
bugs relatively quickly and the level 
designers to talk directly to the texture 
artists. An example of this was the sin- 
gle-player ladder system. Shane Caudle 
designed the art and I wrote the code. 
The fewer people we had to consult in 
order to complete the task meant a 
much faster turnaround. Everyone par- 
ticipated in giving the ''coolness factor" 
thumbs-up or thumbs-down, but the 
actual development process was inten- 
tionally kept thin. 

S Direct communication with the 
# GAMING COMMUNITY. Nearly every 
Epic and Digital Extremes employee 
frequented message boards dedicated 
to the subject of Unreal and Unreal 
Tournament. The majority of Epic 
employees were drawn directly from 
the gaming community, either through 
mod projects or independent game 
work. Keeping in contact with the 
gaming community allowed Epic to 
focus on the target audience during the 
design process. 

Beyond our direct communication 
with the Unreal community, we also 
trolled Quake 3 message boards, read- 
ing the discussions of the fans of our 
lead competitor's game. Learning what 
people liked in a first-person shooter 
and why they liked it helped us change 
the marginal multiplayer experience in 
Unreal to the much faster paced game 
play in Unreal Tournament. 

The gaming community can really 
help set the tone for your game. When 
Unreal was released, the online com- 
munity became extremely vocal and 
angry about the state of the net play. 
While most magazines had reported 
positive experiences with Unreal's sin- 
gle-player mode (reflected in positive 
reviews), the media eventually came to 
reflect the cries of the hardcore gaming 
community. This was in part because 
the net play was poor, but also due to 
the fact that many members of the 
gaming media are themselves hardcore 
game players and visit those same mes- 
sage boards and community outlets. 

We also learned that while the hard- 
core community is very vocal, it is also 
relatively small. Designing a game to 




The characters in Unreal Tournament 
were designed to be futuristic pit 
fighters. The selection of characters 
include ex-military specialists, crimi- 
nals, and alien warriors such as the 
Necris Phayder Assassin pictured 
above. 



appeal to that community alone is a 
critical mistake. Early in 1999 we start- 
ed work on tutorials for each game 
type. The tutorials are far from defini- 
tive, but they did cover the basics of 
playing a 3D shooter. Testing on the 
parents and grandparents of team 
members demonstrated that the tutori- 
als were useful for attracting and keep- 
ing new players. 

This community-mindedness greatly 
contributed to the quality and com- 
pleteness of Unreal Tournament. We 



had a very good idea of what players 
wanted. As I mentioned earlier, we 
often posted controversial design ques- 
tions on public message boards to 
gauge public reaction. The results of 
these polls were taken into considera- 
tion when the feature in question was 
implemented. 

4 Strongly OBJECT-ORIENTED engine 
# DESIGN. The Unreal Tournament 
engine's strong object-oriented design 
makes it extremely modular. This mod- 
ularity allowed our programmers to 
make massive changes to parts of the 
game without affecting other features. 
Each subsystem is connected to other 
subsystems through a clearly defined 
interface, and platform-specific code is 
consigned to separate libraries. Creat- 
ing the Linux port, for example, was 
simply a matter of rewriting an input 
and sound device and writing a Linux 
version of the platform-specific library 
behavior. 

Throughout Unreal Tournament's 
development, Tim Sweeney and Steve 
Polge worked on improving the net- 
working code. The modularity of the 
engine meant that their work didn't 
disturb anyone else's work. Some fea- 
tures, such as Jack's decal system, were 
added very late in the project. The 
decal system added a lot of depth and 
feedback to the game, and took less 
than a week to get working and fully 
debugged. Erik de Neve's mesh level-of- 
detail code touched only a handful of 
source files. 

This ease of use is also reflected in 
the engine's scripting language, 
UnrealScript. Calling it a scripting 
language is a misnomer; it's actually a 
lot like Java. Weapons, pickups, level 
events, AI nodes, and other world 
actors are all independent objects. 
A weapon can be added to the game 
without touching any source files 
but the new object definition. This 
highly extensible language meant that 
each programmer could add extensive 
new game-play features with a very 
limited set of potential side effects. In 
the end, 90 percent of Unreal Tour- 
nament's game-play code was written 
in UnrealScript. 

The Unreal Tournament engine's 
modular package system coupled with 
UnrealEd makes the game a mod- 
creation system out of the box. We 
designed a lot of our code with ama- 
teur extension in mind. Everyone at 
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Epic recognized the value of the mod 
community and we wanted to make 
the game attractive to new artists and 
programmers. Constructing game code 
in this way made it much easier for us 
to prototype our own new features. 
Early UT weapons and pickups were 
child objects of Unreal. The two games 
can easily coexist even now. 

5 Good Timing. As I said earlier, 
# Unreal Tournament was devel- 
oped in the same time period as id 
Software's Quake 3: Arena. The two 
games promised to be of the same 
genre and the two companies were 
known for a high level of competition. 
While we tried to avoid the ''Quake 3 
vs. UT" comparisons, they ultimately 
worked in our favor. The high level of 
public interest in the new engine war 
greatly increased our visibility. Maga- 
zines and web sites often posted split 
previews instead of focusing on one 
game in particular. Interviews with id 
employees would always lead to 
Unreal Tournament questions and 
vice versa. 

Unreal Tournament took almost 
exactly a year and a half to develop, 
giving the team a lot of time to pack in 
features. We didn't have to focus on 
writing an engine from scratch, so we 
were free to focus entirely on improve- 
ments. At this point, we've released 
three patches for Unreal Tournament 
that have solved a handful of relatively 
minor problems. The team has had a 
lot of time available to spend on 
adding even more features to the game 
since its release, instead of fixing out- 
standing issues. By the time this article 
hits the stands, we'll have released our 
first bonus pack: a free collection of 
new models, maps, and game-enhanc- 
ing features. 



What Went Wrong 



IBad timing. Many aspects of the 
# game's timing worked against 
us. While the Quake 3 vs. UT hype 
increased our exposure, it also set a 
very hard deadline for completion. It 
was critical that we complete the 
game before Quake 3 was released. 
The media advantage belonged to id 
and we believed that if Unreal Tour- 
nament launched after Quake 3, we 
would be forgotten in the storm. At 
the same time, however, we were 




After the release of Unreal Tournament, the Epic team started working on a free 
bonus pacl< containing additional models. These are concept drawings of the 
Sl<aarj Warrior model for the pacl<. 




Every weapon in Unreal Tournament 
has two distinct firing modes. This 
made designing and balancing each 
weapon twice as complex as a normal 
first-person shooter. 



caught up in grueling contract renego- 
tiations with GT Interactive. We did 
not want to deliver the completed 
game until we knew the contract 
would work in our favor. Many times 
during the development of the game 
we were promised that a resolution to 
the contract issue was close at hand. 
The team would race to reach a point 
where the game could be shipped. 



The Unreal Tournament development 
team felt that several ofUnreaVs 
weapons were a lot of fun. Here is a 
bot carrying the Shocl< Rifle, an 
updated version of Unreal's ASMD. 



only to have negotiations drag on. 

The gold master was delivered to GT 
days after a final contract was agreed 
upon. Unfortunately, the game hit 
shelves in November, pushing us very 
close to Quake 3's release date. While 
Unreal Tournament often performed 
better than Quake 3 in reviews, we 
believe that sales would have been 
much higher still had we released in 
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October. Word-of- 
mouth is a powerful 
force and the extra 
month would have 
given us time to build a 
larger community 
before Christmas. 

2 No CENTRAL DESIGN 
# DOCUMENT. While 
I am a big supporter of 
open, cabal-style design, 
I have to stop and won- 
der how Unreal Tour- 
nament would have 
turned out had we a 
strong initial design. It's 
quite possible that the 
game's weaker elements 
would have been much 
stronger if we had put 
together some concept 
art and focus material. 
In reviews, we have 
been criticized for not 
having enough variation in charac- 
ters. If Unreal Tournament had had a 
library of concept art to draw from, we 
might have had more interesting alien 
warriors. The story is more or less 
nonexistent in Unreal Tournament, 
but at times we considered having in- 
game cutscenes as rewards for a play- 
er's progress. The idea was dumped, 
but a design document might have 
made it easier to visualize those 
scenes. 

I suppose this isn't really a ''what 
went wrong." It's simply more of a 
''what we should have done." I think 
it's important to think about the game 
in that light. Unreal Tournament is a 
very fun game with a lot of features 
packed into a short amount of devel- 
opment time. Those features were 
largely added through spur-of-the- 
moment decisions. A more unified 
approach to design would have allow- 
ed us to construct features that play on 
features, or even think of ideas we 
didn't have the perspective to realize. 
Epic will always be a very open, liberal 
company when it comes to the design 
process. If we develop a design docu- 
ment, we'll use it with the understand- 
ing that it can be modified at any time. 
That having been said, I think there is 
a definite positive argument for having 
some sort of central guide to every- 
one's ideas. Having the ability to sit 
down and look over the big picture is 
very valuable. 




In the Assault game type, players have to enter a heavily defended 
base and complete map-specific objectives to win. Assault was the 
most difficult Unreal Tournament game type to design, balance, and 
play-test. 




Steve Polge, our A! and game play 
programmer, made the bots under- 
stand the unique advantages and dis- 
advantages of each weapon. Here a 
bot is moving in very close to use the 
powerful Flal< Cannon. 



S Co-development ACROSS two coun- 
# TRIES. Epic Games and Digital 
Extremes co-developed Unreal Tour- 
nament. The Digital Extremes team was 
located in Canada and Epic was located 
in the U.S. Epic supplied the program- 
ming team and a large group of con- 
tent designers. Digital Extremes provid- 
ed level designers, a sound guy, and 
texture artists. James Schmalz, the 
high-up man at Digital Extremes, con- 
tributed two of the game's player mod- 
els and a lot of art. This co-develop- 
ment worked well for the most part, 
but near the end of the project it 
became very difficult. 

During Unreal, Epic team members 
flew to Canada to work at Digital 



Extremes' offices. With 
Unreal Tournament, it 
became Digital Extremes's 
turn to do the traveling. 
Unfortunately, flying and 
driving back and forth 
every couple of weeks is a 
very draining experience. 
Many of the Digital 
Extremes team members 
spent several weeks away 
from their wives and girl- 
friends. Near the end of 
the project, they grew 
increasingly frustrated 
with the situation. To 
compound this problem 
further. Digital Extremes 
and Epic were attempting 
an expensive merger. As 
Unreal Tournament came 
to a close, it became clear 
that the merger would not 
happen. It was prohibitive- 
ly expensive for a small company to 
move across the border. Many Digital 
Extremes team members already had 
apartments and plans for living in 
Raleigh, and the news of the terminat- 
ed merger process was devastating. 

Much to Digital Extremes's credit, 
the company quickly recovered and 
moved to its backup plan of develop- 
ing its own game with the Unreal Tour- 
nament engine. Nonetheless, the 
process of co-developing the game had 
taken its toll on everyone. The ups and 
downs of the merger process had a neg- 
ative effect on team morale. Had the 
co-development happened between 
companies more closely situated, it 
would not have been a problem. 

4 Not enough artists. On the 
# content side. Unreal Tour- 
nament was held back by the number 
of available artists. Epic's artist, Shane 
Caudle, is a supreme Jack-of-all-trades, 
creating skins, models, and levels of 
the highest quality. He spent most of 
his time working on new player models 
and skins for those models. Digital 
Extremes brought a few texture artists 
to the table, but not enough to create 
the huge libraries of new textures need- 
ed for the game. In order to supple- 
ment the skin and texture production. 
Epic turned to contract artist Steve 
Garofalo. 

Even with the additional help from 
external sources, the team was unable 
to produce enough new textures. Level 
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Epic hired several extremely sl<illed 
contractors to assist with art produc 
tion. This is an extremely detailed 
female sl<in by Steve Garofalo. In 
February, Epic hired Steve as a full- 
time team member. 



designers who wanted custom textures 
for their maps had to make do with 
their own texturing ability. While the 
final texture and level count in Unreal 
Tournament is quite high, the levels 
would have been much more impres- 
sive had the team been able to act with 
full freedom. Since the completion of 
Unreal Tournament, Epic has hired 
both Steve Garofalo and John Mueller 
to strengthen the art team for future 
projects. 

5 Visual Basic editor interface. The 
# Unreal Tournament engine 
uses UnrealEd as its level design and 
content management tool. For several 
years, UnrealEd has used a windowing 
interface written in Visual Basic. The 
VB code is fragile and very old. Add to 
this the fact that nobody at Epic except 
Tim Sweeney knows or cares about VB, 
and you have a level design team that 
is stuck with a tool that's not easily 
updated. 

Several interface bugs have plagued 
UnrealEd for some time and nobody 
on the team had the time or inclina- 
tion to fix them. If we had a more easi- 
ly extensible tool, the team would have 
been able to add extra features to the 
editor for level designers to use. As it 
stood, the editor was considered ''off 
limits" for new features. 

For our next few projects we will 
most likely use a new C++ editor that 
Legend Entertainment developed. For 
Unreal Tournament, however, we sim- 
ply didn't have the time to work on a 
new editor. Fortunately, our time spent 
using UnrealEd taught us the dos and 
don'ts of tool design. 

Where Ue Go from Here 

The things that went wrong are, all 
in all, much less significant than 
what went right. Unreal Tournament 
could have benefited from a more 
focused initial design and a more solid 
ship date, but it turned out to be very 
polished and a lot of fun. Many of the 
factors that worked in our favor, like 
timing, also worked against us to some 
extent. ''What went wrong" is a good 
way of looking at what we could have 
done to make Unreal Tournament 
even better. 

Epic has developed some pretty clear 
plans of where we want to go from 
here. We've been working on free con- 



GAME developer may 2000 



tent to release to support Unreal 
Tournament. We are also looking into 
doing some kind of Playstation 2 ver- 
sion of the game. After that, we want 
to focus on an entirely new engine 
technology for the PC. In the short 
term. Jack Porter is working on his 
terrain system and Erik de Neve is 
putting the finishing touches on the 
skeletal animation system. Tim 
Sweeney has been developing an 
entirely new programming language to 
support the next engine, with some 
very powerful features such as parame- 
terized functions. 

Unreal Tournament served as a good 
learning tool for the team. We have a 
good idea of what processes we need to 
adopt to produce larger, more story-dri- 
ven games in the future. We see Unreal 
Tournament as a good lesson in how to 
organize a team and produce a game in 
a short amount of time. The team has 
grown socially, and everyone is much 
more experienced in the process of 
game development. We feel very pre- 
pared to face the upcoming challenges 
and, hopefully, to continue to be seen 
as innovators in the industry. ■ 
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Take Me to Your Leader... 



Patff Sfeed 




abals. Committees. Design by attrition. 
Mean anything to you? Bring on a 
migraine from the experience you had on 
your last project? Make you cringe while 



thinking about how work went today 
on your current project? I bet. 

You see, making computer games 
today is not rocket science. It takes hard 
work, talent, and dedication. It also 
takes leadership. That's right, the dread- 
ed /-word. Everyone seems to want it, 
no one seems to do it right, and the 
ones most qualified to be in the cap- 
tain's chair are usually sporting a tight 
red shirt, beaming down with the next 

away-team. In order ^ 

to succeed, a game /f~^ 
has to have leader- 
ship throughout the 
course of its devel- 
opment. Sure there 
are exceptions, but 
even in cases where 
it seems a single 
person isn't at the 
helm, there really is 
someone who had a 
vision and main- 
tained it through- 
out the develop- 
ment process. (He's 
the guy behind the curtain.) 

I didn't pick up a mouse until I was 
27 and even though I've been making 
art for computer games for almost nine 
years, I'm still astounded by the lack of 
emphasis many companies place on 
structure in the development process. I 
know why, though. It's that leadership 
thing. Maybe I'm just more acutely 
aware of it having served six years in 
the Air Force, but it bugs me greatly 
that in the time I spend pushing pixels 
and vertices, concepts like "chain of 



command" are deemed too militaristic 
and constrictive for our industry. 

What's wrong with a little order? 
What's wrong with a little discipline? 
What's wrong with knowing without a 
doubt who the right guy to turn to is? 
What's wrong with making sure the per- 
son in charge of the vision for the game 
has at least the basic social skills needed 
to communicate to the rest of the team? 
Nothing. But lapses in leadership hap- 




pen all the time. Whether it's a case of 
the wrong person leading the team or 
no one being willing to make a decision 
without ratification by a ten-man com- 
mittee, more often than not games are 
made in a storm: a storm of inclement 
social and team dynamics. Such bad 
weather can always be traced to the top. 
Think about it. When the director of a 
project is passionate, committed, com- 
municative, and willing to be flexible 
while creating his or her opus, guess 
what happens? It's infectious. All the 



other team members get those same 
symptoms leading to one hell of a prod- 
uct. But before we get into the impor- 
tance of having a good captain at the 
helm, let's talk about the ship. 

Without the right people, nothing 
else matters when making a game 
today. Money doesn't matter. Swanky 
location doesn't matter. Nothing mat- 
ters. This crew has to be a group of tal- 
ented, hard-working, passionate indi- 
viduals working together as a team. As 
individuals, each person must be more 
than just competent. They have the 
ability, and more importantly, the 
desire to solve problems. They're profes- 
sionals in their given areas of expertise 
and proud of their work. Eager to 
impress, they nonetheless understand 
the value of teamwork 
^ and clear communica- 
I ^- J J I tion. They don't have 
\ ^ { to have one, but an 
^^k^^ occasional pat on the 
back goes a long way, 
even if they don't 
always show it. 

Feedback and direc- 
tion from the project 
leader sustains the 
members of the team 
as they plod through 
the long, hard trek 
that is making com- 
puter games today. 
Not knowing if they're doing a good 
job, a bad job, or even an adequate job 
will hurt morale. Not knowing what 
they're supposed to be doing and 
whether what they're doing is correct 
will quickly herd a team into disaster. 
This is where the leader comes in, not 
only through carefully monitoring the 
morale and status of the team, but by 
successfully communicating his or her 
vision to them. 

The importance of having a coherent 
Continued ON page 63 
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Continued from page 64 

vision for a game idea can't be overstat- 
ed. The project leader has to hold on to 
the vision, know it, and convince 
everyone else of his or her commit- 
ment to it, so that everyone else can in 
turn embrace and become excited 
about it. This is most evident through a 
well-written (and evolving when neces- 
sary) game design document. An effec- 
tive design document gives form to the 
vision and adds to the team's comfort 
level as they settle in for the long haul. 
Without this bible in hand, it's impos- 
sible to maintain and communicate the 
vision for the game to the rest of the 
team. But the term ''bible" should be 
used loosely. 

The key to a good game design docu- 
ment is lucidity and flexibility. It has to 
identify important aspects and concepts 
of the design clearly and quickly so that 
they can be translated into workload. It 
is a road map and a starting point for all 
phases of preproduction and produc- 
tion. Don't make a phone-book-sized 
tome and expect everyone (or anyone) 
to read it. A well-written design docu- 
ment exists in three iterations: one 
page, ten pages, and one hundred pages. 
All will read the one-page version, most 
will read the ten-page version, and few 
if any will read the one-hundred-page 
version. It should be visually interest- 
ing, not bogged down by flowery prose. 
Revisions to the document should be 
followed effortlessly. Flexibility in the 
design document means that changes 
can be incorporated if existing ideas 
aren't working out or can't be executed. 
Clinging tenaciously to an aspect of the 
design when it's apparent it won't work 
is bad. It's a sign of pride over reason 
and a sign of bad leadership. 



So what about the leader himself? 
What does it really take to be the cap- 
tain of the starship? Good organiza- 
tional skills, good communication 
skills, and good people skills are a 
must. Expressing endless passion and 
unrelenting drive helps as well. When 
people sense your commitment, they 
become committed as well. If they 
think you have your act together then 
they'll strive to keep their act together 
and execute the plan you've devised 
with aplomb. Of course, a dictatorship 
doesn't inspire any sort of devotion or 
esprit de corps. Barking orders and dis- 
regarding what others have to say 
won't work. Having confidence in your 
leadership ability means just that — 
throwing temper tantrums when 
things don't go your way is the surest 
and quickest way to turn off your team. 
Resolving sticking points during the 
development process by demonstrating 
tact and diplomacy isn't the easiest 
thing to do, but it is the most effective. 

Does leadership necessarily have to 
rest on the shoulders of one person? 
Yes, it does. Leadership by committee 
just doesn't work, especially if the 
team is small. Too many chiefs, not 
enough Indians; too many cooks in 
the kitchen — whatever saying comes 
to mind can be applied here. Going to 
one person for answers saves time and 
confusion, allowing for (gasp!) projects 
to be done on time. By contrast, com- 
mittees are invariably bogged down by 
politics and wasteful bickering. In our 
industry, too often the decision-mak- 
ing process is way too complicated and 
involves way too many people. That's 
not to say democracy should be 
thrown out the window, quite the 
opposite. If a leader is on the ball, he 



or she already knows what the general 
consensus on any issue is. Leaders 
should never be afraid to make deci- 
sions and deal with the consequences. 

Finally there's commitment: doing 
whatever it takes to get the job done. 
Effective, confident leadership creates 
an environment where synergy and 
camaraderie grow through the under- 
standing that effort won't be wasted 
and will be appreciated. But in the 
end, everyone, not just the leader of 
the team, has to commit unflaggingly 
to their abilities and the game's 
premise in order celebrate a successful 
finished result. 

At the heart of it is this: Good leader- 
ship is about conveying your vision to 
the rest of the team effectively. A leader is 
not a shy person. A leader is not one of 
the socially challenged. Having 
embarked upon the arduous journey 
that becomes the game development 
process, a team needs to know that a 
competent and skilled captain is at the 
helm. All the team members need to 
know well beforehand what is expected 
of them and what they need to accom- 
plish to support the project's various 
milestones. The leader of the project 
must provide direction so that members 
of the team know at all times that what 
they are doing is right and what they 
need to be doing in the future. When 
communication falters, so does the pro- 
ject. The team will flounder, turn on 
itself, dissolve, or complete a project 
that results in a marginal game at best. 

Successful games don't happen by 
accident. A good leader commits, moti- 
vates, communicates, and in the end 
inspires the rest of the team to stick it 
out and care about what they do. A 
good leader leads. ■ 



